Необходимо хранить логи по всем действиям со всеми документами.
Объём данных : порядка 5 млн записей в сутки, а это около 2 млрд записей в год.
Структура данных: дата-время записи + идентификатор документа + всё остальное (сейчас порядка 20 полей, но список пересмотрим, скорее всего увеличим)
Сейчас это всё хранится в MS SQL. Что не устраивает:
из-за огромного объёма данных сервер их еле крутит

из-за огромного объёма данных запросы работают только по первичному ключу таблицы (документ), а хотелось бы проводить какую-либо аналитику по дате, возможно по другим полям
Что хотелось бы:

разнести данные по нескольким серверам, т.к. мощности 1 сервера явно не достаточно

делать выборки 2 типов: получать логи по 1 документу (индекс - документ) и получать выборку для анализа за период (индекс - дата)
Пробовали использовать Yandex ClickHouse - по началу устраивал, но с данными за пол года начал тормозить. Возможно не так настроили - сейчас перебираем варианты конфигураций. Также есть проблема с получением данных, на которую на форумах не могут ответить, а в документации не описываются такие детали. В общем сейчас стоим перед выбором: пытаться дальше тратить силы и разбираться с системой, либо попробовать другую.
Следующий кандидат на тестирование - Cassandra (+ spark поверх неё). Но чтобы создать 2 индекса необходимо будет, фактически, иметь 2 копии данных - каждую под свой индекс, что сильно скажется на занимаемом месте.
Возможно есть более подходящие системы.
Хотелось бы услышать мнения о том, какая система, на ваш взгляд, лучше подойдёт под нашу задачу?

Alexey TominMax_11111Необходимо хранить логи по всем действиям со всеми документами.
Объём данных : порядка 5 млн записей в сутки, а это около 2 млрд записей в год.
...
Хотелось бы услышать мнения о том, какая система, на ваш взгляд, лучше подойдёт под нашу задачу?

hdfs+spark.
Индекс- предагрегация с сохранением по нужному ключу.
Пытался как-то поднять hadoop самостоятельно по мануалам - так и не осилил эти костыли. Есть готовые бесплатные сборки, желательно уже с Hive?

Alexey Tomin,

Спасибо, рассмотрим этот вариант

servit Max_11111 ,

Может быть пока сосредоточиться на оптимизации/донастройке MSSQL?
И что говорят на соседнем форуме относительно вышеозвученных проблем/пожеланий?
Думаю с таким объёмом данных ресурс MS SQL уже исчерпан. Наличием дополнительного индекса проблему не решить, можно попробовать колоночное хранение, но мешаются текстовые столбцы с произвольными комментариями.
К тому-же очень хочется проводить какую-либо аналитику (какую, честно, сами ещё не решили. для того лог и собирается чтобы потом что-нибудь поанализировать), что не получится сделать на огромной таблице на одном сервере в MS SQL

servitПрежде чем принимать решение о переходе на совершенно что-то новое для себя и/или команды, следует выжать всё возможное из текущего. Пока же потенциал продукта у ТС кмк не исчерпан.
SQL можно оптимизировать под конкретные запросы: накинуть индекс чтобы отобрать как можно меньше данных и дальше из вывести или обработать. Обработку миллиардов строк в одном запросе SQL не потянет. А мы хотим именно так и делать - в идеале анализировать данные за весь период и искать скрытые закономерности и исключения (например ошибки в бизнес-процессах или махинации)
servitPS: а про то, как выбирают СУБД в современной действительности, можно почитать в моём блоге.
Похоже что так мы и выбрали ClickHouse и теперь сталкиваемся с теми-же проблемами, которые указаны на слайдах.

Значит пока 3 варианта:
HDFS + Spark (у нас есть питонисты, поэтому данное решение очень интересно)
HDFS + ELK (зоопарк технологий, но почему бы не попробовать)
Cassandra + Spark

servitДля аналитики всё же используют не SQL, а MDX. И да, в одном MDX-запросе могут быть задействованы (не напрямую, а опосредованно) миллиарды, триллионы строк и это нормально.
Есть СУБД с изначально многомерной моделью хранения данных, которые прекрасно сопрягаются как с SQL, так и MDX и даже объектами.
OLAP тут явно не подойдёт. Мне нужны не агрегаты, в цепочки последовательностей