Эмм... для начала нужно выучить мат часть и разобраться что такое B-tree и R-tree и как они фигурируют в современных СУБД, разобраться что такое "6ая нормальная форма" (второй курс универа).
Если это мускуль у которого "бесконечная длинна" таблички - от 200Гб и до 1Тб, то достаточно просто использовать ENGINE ARCHIVE c R-tree индексом. В противном случае (если меньше 200Гб) нужно (учить мат часть и вправлять мозги) рефакторить базу. Лучше слезть с MySQL на PostgreSQL, а вот c MongoDB - куча проблем. Стандартные СУБД на основе B-tree для баз от 200Гб+ не подходят. MySQL исключение из-за модульности системы хранения, имеется ввиду ENGINE ARCHIVE, но так как там нет T-tree - нужен нормальный кэш. PostgreSQL даже похуже будет - нужно ковырять различные расширения типа cstore_fdw и т.п.
uint64 ID'шник в виде хэша - очень спорное решение, даже если и предположить что в какой-то вселенной нет коллизий, то точно не в этой, и дополнительно нужно прогонять фильтр Блума. Хотя, лучше всего, просто использовать композитные ключи и не заморачиваться.
Можно ещё попробовать HBase в Apache Phoenix обернуть, там уже есть всё готовое - и фильтр Блума и индексация, можно даже X-tree оформить. HBase, кстати, хорошо масштабируется на запись, а Cassandra, наоборот, - на чтение.
Шардинг (партицирование) и репликацию нужно оформлять когда схема хорошо нормализирована, и когда более-менее ясно какие таблички нужно масштабировать на запись, а какие на чтение - где-то нужен CA, где-то CP, а где-то AP... (CAP теорема)
Очень весело в PostgeSQL писать сишные функции для агрегации в материализованные представления, особенно весело с GPGPU.
Простой
Простой
Средний
Сложный
Средний
