В какой базе данных хранить одну большую таблицу?

Question

[andrew_tch]

Привет!

Есть данные, одного типа, но их очень много. По сути, это события из системы метрик - у события есть timestamp, и с пяток полей описания. У событий только один тип, по сути это JSON документы.

Надо что-то, где можно будет события хранить (по сути это одна таблица), данных очень много (сотни миллионов, миллиарды строк) и за разумное время делать выборку (например, выбрать все записи с host = foobar, или с type = emergency).

Где разумнее всего такое хранить? Mongodb? Riak? Couchdb? Plain old SQL?

Спасибо!

Answer 1

[sim3x]

Postgresql

json разложить по таблицам (нормализовать -- избавиться от повторяющихся текстовых значений), сделать индексы, при необходимости, сделать партиционирование

Comments

[lega]

нормализация головного мозга

[sim3x]

lega: ?

[lega]

sim3x: нормализация для логов - как гвозди микроскопом, т.е. инструмент не по задаче

[sim3x]

lega: запрос по логам более нелепая задача, чем вставка структурированной информации ака лог в бд

[andrew_tch]

Вставлю пять копеек - Hadoop это и есть "запрос по неструктурированным логам", например, и нормализация там не нужна

[sim3x]

andrew_tch: логи не являются неструктурированной информацией

[nirvimel]

+1
Если планируется выборка по значениям отдельных полей в документе, то на этот документ следует смотреть уже как на запись в таблице. Попытки уйти от RDBMS в погоне за скоростью приведут к еще большим проблемам - придется городить собственные индексы на костылях, убить на разработку этого кучу времени и внезапно получить в итоге расход места на диске больше, а производительность ниже чем у Postgresql.

Answer 2

[lega]

У Яндекса есть clickhouse для метрик, можете попробовать.

Какое железо хотите под это дело использовать?

миллиарды строк

например 10 миллиардов могут занять 600Гб на диске, один индекс 100-600Гб (оперативы), больше индексов - больше памяти. Т.е. тут стандартные подходы не рулят.

Я для подобного делал партицирование + сжатие + пред-кеширование, итого 600Гб превратились бы в 10Гб на диске и 0,4Гб на индексы. Ну и скорость выборки выросла в ~100 раз по сравнению с обычным подходом (выбирать по строкам из таблицы).

Comments

[latteo]

А сжатие как осуществлялось?

[lega]

latteo: все данные резались на чанки и запаковывались, каждый чанк имел свои индексы.
Резать чанки надо так, что-бы максимально эффективно потом можно было доставать, т.е. под запросы.
Очень часто одним из индексом бывает время, т.к. данные обычно запрашивают за какой-то период, а не за всю историю. Т.е. идет нарезка на часы/дни/месяца и т.п. Далее день нарезается на второй (третий) индекс. Чанки паковались xz/bzip без заголовков, и разъезжались по шардингу. Использовалось максимальное сжатие т.к. чтение редкое, а хранимые данные занимают место постоянно.

Итого запросить и распаковать 500 чанков горадзо быстрее чем извлечь 500М строк из БД. + большая экономия на памяти и индексах.

Answer 3

[Everything_is_not_so_bad]

Попробовать поискать на тему "time series database" (TSDB): может всякие типа Akumuli, InfluxDB и прочие.
Такие СУБД лучше справляются с большими объёмами данных временных рядов, нежели обычные РСУБД типа Постгрес.