Коллеги, приветствую!

Помогите советом, плз!

Есть задача: нужно хранить таблицу данных которая со весеннем не будет влезать на одну машину. В таблице есть несколько полей по которым нужно осуществлять поиск, пэгинацию и сортировку соответственно. Но поиск и сортировка должны осуществляться на частях этой таблицы. Пример: таблица городов. Мы берем страну и города в ней нужно уметь сортировать по количеству жителей, по площади и например по типу. Так же нужно уметь фильтровать записи и пэгинацию для вывода на фронт. Как вы понимаете, фронт от всех городов в России умрет. Да, сложные фильтры не нужны, т.е. фильтр только по одной колонке.

Если бы влезало на одну машину, то без вопросов взял бы rdbms. Можно так же шардировать по стране. Но мне кажется, что когда в rdbms появляется Шарлин, то это уже не ее задача. Есть мысль, что нужно nosql решение. В документных бд опыт небольшой и часто слышу про потери данных. По CAP теореме нужно скорее CP. Расстрел SSTable Cassandra (replication factor 3). Вроде ложиться ключ распределения - страна. Но для каждой сортировки в ней нужно делать отдельную таблицу. Т.е. в каждой разный кластерный ключ для сортировки и поиска. 

Подскажите, насколько оправдан выбор касандры? Может можно сделать проще?

Может посмотреть в сторону elasticsearch и подобных ?
Учитывая что вам все таки искать надо.

"По итогам Всероссийской переписи населения 2010 года статус города имеют 1100 населённых пунктов" -- да блин, чем вы там этот фронт пишэте, что он от таблички на 1000 строк помирает?

Ну да, если под каждый город создавать небольшой фрэйм, в нём 15-20 тэгов, к каждому тэгу привешэн объект-контроллер, каждый объект-контроллер унаследован от 4  родителей, два из которых имеют ссылку на "реальную реализацыю", и вся эта тряхомудия последовательно перебирается при каждом движэнии мышы для поиска цэли этого сообщения -- то да. Умрёт. Но так можно сразу функцыю Акермана от этого количества вписать -- оно тогда от 5 городов умрёт.

Добавлено через 6 минут и 53 секунды
И да, если у вас и правда всякие типа-города, только считать будете со всеми деревнями -- то их 150000. Написать сейчас фронт, чтобы он не умер от этого количества можно, но ужэ действительно требует некоторых умственных усилий.

Но для типичной СУБД на бэкэнде это вообще не размер. 150000 записей нормального размера успешно управляются примерно чем угодно, включая sqlite.

Неудачно пример привел. Будет примерно 10млрд записей

Добавлено через 1 минуту и 47 секунд

Спасибо. А как хорошо оно шардится? 10млрд записей