Структура моих данных следующая:
date: <timestamp>
filter_a: <integer> -> range [0, 1000]
filter_b: <integer> -> range [0, 1000]
filter_c: <integer> -> range [0, 86400]
filter_d: <integer> -> range [0, 6]
group: <string>
second_group: <integer>
variable_a: <float>
variable_b: <float>
variable_c: <float>
a couple more no very importantМне нужно выполнить следующие запросы:
Первый:
- Фильтрация данных по
date,filter_a,filter_b,filter_cи др
Во-вторых, с отфильтрованными данными:
- считать все записи
- получить среднее из
variable_a,variable_bиvariable_c - получить стандартное отклонение от
variable_a,variable_bиvariable_c - получить квартили из
variable_a,variable_bиvariable_c - группировать данные по
groupилиsecond_groupи агрегировать (Count, Avg, Std, ..)
Число пользователей системы составляет около 10 или 15, но количество элементов огромен, прямо сейчас 70М , но это будет 500M в течение нескольких недель , и это будет 1000M примерно через год.
Количество запросов небольшое, не более 10 пользователей одновременно, моя проблема в том, как обрабатывать эти запросы с таким огромным количеством данных.
Что я пробовал до сих пор?
Я начал с того
mongodb, что вначале это было быстро, но стало медленным при расчете квартилей с 10М +. Это улучшилось, когда я добавил индексы, но это не очень помогло, когда мне пришлось запрашивать все данные. Я начал использовать mongodb, потому что данные были очень динамичными, но, к счастью, формат данных «больше не изменится».Как
filter_aиfilter_bможно было увидеть как узлы, я попробовалneo4j. Мне очень понравилось это neo4j, но у моего графа было МНОГО ребер, поэтому запросы не были очень быстрыми.Наконец, поскольку формат данных не собирается меняться и это всего лишь одна коллекция / таблица, поэтому не требуется никаких соединений в SQL, я проверил postgresql. Мои тесты были быстрее с postgresql, но я боюсь, что в будущем он не сможет масштабироваться должным образом.
Что мне нужно?
- Является ли postgresql хорошим выбором для этого случая?
- Могу ли я использовать другую базу данных? какой из них лучше для этого случая?
- Что еще я мог сделать, чтобы улучшить это?
редактировать
- Около 1 млн элементов вставляются каждый день и «не должны меняться» с течением времени.
- Скорость записи не важна
- Сложное требование - быстро читать / агрегировать
Спасибо!
Ответы:
Вместо того, чтобы опираться на реляционную базу данных для выполнения этих статистических вычислений на данных временных рядов, я бы предложил перенести эту работу по математике и последующей обработке за пределы базы данных в клиентское приложение.
Используя язык сценариев, такой как Python или Ruby, вы можете поэтапно решить проблему, выполняя запросы на «порции» данных за фиксированный промежуток времени, вычисляя промежуточную статистическую сводку, а затем комбинируя результаты по нескольким порциям в цикле на протяжении всей истории. Некоторые статистические показатели сложно объединить между частями, но что-то вроде Avg () требует только sum () и count () для каждого чанка, O (1) и O (размер чанка), поэтому объединение чанков может хорошо масштабироваться.
источник
chunksizeможет помочь. +1Поскольку ваши данные не меняются, а только добавляются, я буду хранить данные где угодно; Amazon S3 например, но любая быстро читаемая база данных будет в порядке. Нет индексов. Выбранная вами база данных / ФС должна иметь возможность считывать данные в контейнерах: например, вы можете иметь один файл в день с вашими записями 1М.
Тогда я бы использовал Spark для фильтрации / анализа. Он основан на кластерах, вы можете масштабировать его под свои нужды.
источник
Ответ зависит от того, как вы собираетесь использовать данные после этого. Если для обработки лучше использовать Cassandra, если для анализа лучше использовать Hive.
источник
real time. Я ошибаюсь?Такая ситуация идеальна для хранилищ данных, использующих методы, усовершенствованные Ральфом Кимбаллом и его коллегами, на платформах, подобных SQL Server (та, с которой я больше всего знакома). Они были разработаны специально для этого типа сценария: огромные объемы записей данных, которые являются относительно статичными, для которых вам нужно рассчитать агрегаты такого рода. нетреляционная техника будет подходить для правильно реализованного хранилища данных в приложениях такого рода, хотя некоторые, безусловно, будут лучше, чем другие, если ваша организация просто не может позволить себе лицензии на пакеты программного обеспечения (например, службы анализа SQL Server), которые их реализуют. Существует также кривая обучения внедрению таких языков, как MDX, которые специально разработаны для такого рода доступа к данным. Если хранилище данных является жизнеспособным вариантом для вашей организации, не тратьте время на поиск реляционного решения; это не проблема реляционной базы данных. Я могу опубликовать некоторые основные ссылки на Kimball и т. Д., А также ссылки на SSAS и MDX (извините, я не могу помочь с Oracle и другими конкурентами, с которыми я не знаком) документацию, если это необходимо. Надеюсь, это поможет.
источник