БД для исторических данных
Давай попробуем разобраться в задаче. У тебя эти данные откуда: результаты эксперимента, импорт из другого источника?
Какие запросы будут к данным? Если много агрегации, то с большой вероятностью подойдёт nosql кластер (mongodb, couchdb).
По предложенным вариантам: mssql compact — упрёшься в 4гб лимит размера (ну, или сколько там).
kdb+ — интересный вариант, но вряд ли кто здесь пробовал с ним работать, эксперименты придётся самостоятельно провести. И по-моему она платная.
Какие запросы будут к данным? Если много агрегации, то с большой вероятностью подойдёт nosql кластер (mongodb, couchdb).
По предложенным вариантам: mssql compact — упрёшься в 4гб лимит размера (ну, или сколько там).
kdb+ — интересный вариант, но вряд ли кто здесь пробовал с ним работать, эксперименты придётся самостоятельно провести. И по-моему она платная.
Ещё не хватает определения кол-ва тиков в секунду и объема данных за один тик. Чтобы хотя бы примерно оценить объем хранимых данных.
для истерических
У тебя эти данные откуда: результаты эксперимента, импорт из другого источника?Данные, которые сейчас представляют собой набор файлов (по большей части excel
необходимо агрегировать в одном месте. Каждый файл - это данные по одному инструменту,
например, цена определенной акции. Таким образом, файл представляет собой три колонки,
первая - дата, вторая - время, третья - цена. Частота ~ 1 сек.
Какие запросы будут к данным?Запросы планируются следующие - добавить новую запись по определенному инструменту;
извлечь данные по акции, удовлетворяющие определенным временным промежуткам,
например, конкретный день с 12:00:00 до 12:00:05.
mssql compact — упрёшься в 4гб лимит размера (ну, или сколько там).Спасибо, что предупредил - 4гб - ни в какие рамки не лезет. Хочется от нескольких терабайт.
kdb+ — интересный вариант, но вряд ли кто здесь пробовал с ним работать, эксперименты придётся самостоятельно провести. И по-моему она платная.Там есть 32битная - условно бесплатная - но она лишь на 90 дней, после необходимо перерегистрировать/переустанавливать. Поэтому тоже не айс.
А как насчет mysql?
Спасибо за уточнение.
Пусть 1тик = 1 сек.
Объем данных за 1 тик, 200-300 float'ов.
Пусть 1тик = 1 сек.
Объем данных за 1 тик, 200-300 float'ов.
Запросы планируются следующие - добавить новую запись по определенному инструменту;Добавлять данные в текстовый файл, каждые сутки новый
извлечь данные по акции, удовлетворяющие определенным временным промежуткам,
например, конкретный день с 12:00:00 до 12:00:05.
какую БД для хранения исторических данных лучше всего развернутьhttp://www.realcoding.net/article/view/4495
ключевое слово "секционирование данных". ы?
А как насчет mysql?А вот хз. По мускулю я не эксперт. Но всё кажется просто: создай схему с индексом (словами ты её уже описал нагенерируй пару ТБ мусора, посмотри, с какой скоростью они записываются-считываются.
А какая latency допускается для запроса на выборку?
В мускуле есть. Partitioning.
Любая SQL-база с partitioning по дате.
А как насчет mysql?Если считать 500 записей в секунду, то это получается под два миллиона в час.
Можно попробовать посмотреть, как себя ведет innodb и myisam, если включить почасовое партиционирование. Если запросов к этой БД будет мало (тут надо детально смотреть то я бы вообще оставил эту всю штуку без индексов на full scan - сильно выиграешь по скорости при записи.
В мускуле есть. Partitioning.Печально, что они для партиционированных таблиц выключили INSERT DELAYED @ MyISAM.
> Пусть 1тик = 1 сек. Объем данных за 1 тик, 200-300 float'ов.
Если примем флоат за 4 байта, таймстэмп за 8, это будет (8+4) х 500 х 9 х 3600 (бизнес открыт 9 часов из 24х, флоатов взял 500 за тик с запасом) ~= 180MiB/сутки.
Такими темпами первый терабайт ты наберешь только через 15 лет.
Для выбора очень важно понимать, какая нагрузка будет по выборкам. Queries per second? Насколько большой рэндж по датам в выборке? Какое время отводится на ответ?
Вообще, если особых требований к выборкам нету, то велосипедная реализация, как заметил , пожалуй, будет оптимальна.
Данные поступают в заранее отсортированном порядке, будучи один раз записанными никогда не меняются. Выборки идут по протяженным кускам. Рай =)
Пишем, скажем, по файлу на неделю - это будет порядка 200к строчек на файл.
Банальный бинарный поиск справится за <20 итераций. То есть это 20х10ms_seek_time ~= 200ms на поиск данных и еще сколько то на вычитывание ренджа. Соотв на небольших ренджах в 300мс уложишься.
Решение отлично масштабируется по объему данных - ему на него просто чихать.
Если примем флоат за 4 байта, таймстэмп за 8, это будет (8+4) х 500 х 9 х 3600 (бизнес открыт 9 часов из 24х, флоатов взял 500 за тик с запасом) ~= 180MiB/сутки.
Такими темпами первый терабайт ты наберешь только через 15 лет.
Для выбора очень важно понимать, какая нагрузка будет по выборкам. Queries per second? Насколько большой рэндж по датам в выборке? Какое время отводится на ответ?
Вообще, если особых требований к выборкам нету, то велосипедная реализация, как заметил , пожалуй, будет оптимальна.
Данные поступают в заранее отсортированном порядке, будучи один раз записанными никогда не меняются. Выборки идут по протяженным кускам. Рай =)
Пишем, скажем, по файлу на неделю - это будет порядка 200к строчек на файл.
Банальный бинарный поиск справится за <20 итераций. То есть это 20х10ms_seek_time ~= 200ms на поиск данных и еще сколько то на вычитывание ренджа. Соотв на небольших ренджах в 300мс уложишься.
Решение отлично масштабируется по объему данных - ему на него просто чихать.
Есть еще http://www.scidb.org/, но он больше под "научные данные" заточен.
Ты бы конкретизировал, что за исторические данные, в каком объеме и что ты с ними планируешь делать.
Ты бы конкретизировал, что за исторические данные, в каком объеме и что ты с ними планируешь делать.
Прочитал описание твоей задачи — имхо http://www.postgresql.org/ тебе нужен.
kdb+ — интересный вариант, но вряд ли кто здесь пробовал с ним работать, эксперименты придётся самостоятельно провести. И по-моему она платная.Я работал, но в случае топикстатера это как томагавком по комару пулять.
как томагавком по комару пулять
Все равно не попадешь?
Задача топикстартера решается в ней условно говоря за 1 минуту.
Спасибо, можешь пояснить, почему ты так думаешь?
Прозвучавшие в треде (и не только) кандидаты:
- mssql
- mysql
- sqllite
- postgresql
Не могли бы вы сказать, в чем отличие этих четырех?
Еще кандидаты:
- Plain text/csv/binary files
- HDF5
- KDB
Заранее благодарю.
Прозвучавшие в треде (и не только) кандидаты:
- mssql
- mysql
- sqllite
- postgresql
Не могли бы вы сказать, в чем отличие этих четырех?
Еще кандидаты:
- Plain text/csv/binary files
- HDF5
- KDB
Заранее благодарю.
Она и стоит...
Не для нищебродов, это верно. Но позволить себе роскошь иметь данные с рынков за несколько лет могут только богатые финорганизации, вот и цены такие.
mssql забесплатно не поддерживает Терабайты данных как тебе хочется. Не факт, что тебе это нужно, ну да ладно.
mysql не богат на функционал. Не факт, что тебе в действительности потребуются различные фичи SQL, которых нет в MySQL, ну да ладно. Кстати, у MySQL-я тоже не понятно, что будет с платность/бесплатностью. Есть его ветка MariaDB — будет всегда бесплатная, но она отделилась порядка двух лет назад, что будет в будущем не очень понятно.
sqlite — легкий, но ограниченный.
postgresql — медленее MySQL, но поддерживает много фич.
Ну вот это если вкратце. А вообще выбери что-то одно, попробуй — если не будешь сильно выходить за пределы "стандартного" SQL, то поменять базу данных будет несложно.
В итоге выберешь что именно тебе подходит.
У меня было одно решение, когда одни данные хранились в SQLite, часть писалась в MySQL, а потом это все оттуда и из бинарных файлов обсчитывалось вместе, и результаты писались в Postgres, где уже была сделана бизнес-логика.
mysql не богат на функционал. Не факт, что тебе в действительности потребуются различные фичи SQL, которых нет в MySQL, ну да ладно. Кстати, у MySQL-я тоже не понятно, что будет с платность/бесплатностью. Есть его ветка MariaDB — будет всегда бесплатная, но она отделилась порядка двух лет назад, что будет в будущем не очень понятно.
sqlite — легкий, но ограниченный.
postgresql — медленее MySQL, но поддерживает много фич.
Ну вот это если вкратце. А вообще выбери что-то одно, попробуй — если не будешь сильно выходить за пределы "стандартного" SQL, то поменять базу данных будет несложно.
В итоге выберешь что именно тебе подходит.
У меня было одно решение, когда одни данные хранились в SQLite, часть писалась в MySQL, а потом это все оттуда и из бинарных файлов обсчитывалось вместе, и результаты писались в Postgres, где уже была сделана бизнес-логика.
Спасибо,
это официальное мнение или повод для холивара?
postgresql - медленее MySQL?
это официальное мнение или повод для холивара?
Это мое личное мнение.
Ну то есть в том "мега-проекте" что я описал до этого, в MySQL писались некоторые данные, которые если писать их сразу в Postgres, то система не справлялась.
Попутно встречал подобное решение MySQL + Postgres в интернете несколько раз, поэтому и считаю его правильным.
Ну то есть в том "мега-проекте" что я описал до этого, в MySQL писались некоторые данные, которые если писать их сразу в Postgres, то система не справлялась.
Попутно встречал подобное решение MySQL + Postgres в интернете несколько раз, поэтому и считаю его правильным.
А вообще выбери что-то одно, попробуй — если не будешь сильно выходить за пределы "стандартного" SQL, то поменять базу данных будет несложно.если нужна скорость, то придется выходить за пределы sql.
как минимум для быстрой заливки данных в БД, каждый движок предлагает свою функциональность.
зы
мы делаем на mssql, при правильном его использовании - получается лить миллион записей в минуту
это официальное мнение или повод для холивара?Повод для холивара.
при правильном его использованииа можно поконкретнее
часть советов в треде уже было.
partition, по минимуму индексов, заливка данных через bulk insert или аналог
partition, по минимуму индексов, заливка данных через bulk insert или аналог
мы делаем на mssql, при правильном его использовании - получается лить миллион записей в минутуэто много что ли
это много что лине очень, но под наши задачи хватает. быстрее не разгоняли.
это было написано к тому, что у ТС в минуту будет литься 30к записей, что дает ему 30 кратный запас прочности
это много что ликстати до какой скорости можно разогнать на desktop-ном железе?
SSD ощутимый выигрыш дает? и в каких сценариях?
кстати до какой скорости можно разогнать на desktop-ном железе?1) Desktop'ное железо бывает разное.
2) Технология INSERT DELAYED и подобных фич в других СУБД упирается не в диски, а в объем и скорость ОЗУ.
2) Технология INSERT DELAYED и подобных фич в других СУБД упирается не в диски, а в объем и скорость ОЗУ.так если нагрузка постоянная, а не пиковая, на диск-то все равно рано или поздно придется писать.
как здесь insert delayed помогает?
зы
млн/минута - это именно постоянная нагрузка, из-за дня в день
1) Desktop'ное железо бывает разное.разница в 2-3 раза, на порядок разница уже едва ли будет
так если нагрузка постоянная, а не пиковая, на диск-то все равно рано или поздно придется писать.это позволяет снизить кол-во записей на диск, дав возможность SQL движку самому решать, когда надо данные флашить.
это позволяет снизить кол-во записей на диск, дав возможность SQL движку самому решать, когда надо данные флашитьимхо, особой разницы не должно быть от той же пакетной вставки 10тыс. записей.
и там, и там объем достаточный, чтобы оптимально сделать дисковые операции
зы
но проверить конечно стоит
на определенном характере нагрузки такая стратегия даёт очень большой выигрыш.
у меня перед глазами пример, когда отложенная запись (INSERT DELAYED) на диск, расположенный в ОЗУ (memory-mapped), экономит примерно 30% времени работы программы, которая снимает очень много данных (1M датчиков) с кучи коробок по SNMP.
у меня перед глазами пример, когда отложенная запись (INSERT DELAYED) на диск, расположенный в ОЗУ (memory-mapped), экономит примерно 30% времени работы программы, которая снимает очень много данных (1M датчиков) с кучи коробок по SNMP.
которая снимает очень много данных (1M датчиков) с кучи коробок по SNMP.какой период съема данных?
раз в 5 минут.
зависимость времени исполнения от кол-во одновременных тредов (1 тред на хост):
Hosts:1741 HostsPerProcess:1741 DataSources:882544
SYSTEM STATS: Time:49.3651 Method:spine Processes:1 Threads:16
SYSTEM STATS: Time:27.2454 Method:spine Processes:1 Threads:32
SYSTEM STATS: Time:23.7068 Method:spine Processes:1 Threads:40
SYSTEM STATS: Time:21.6130 Method:spine Processes:1 Threads:48
SYSTEM STATS: Time:19.5370 Method:spine Processes:1 Threads:64
Если убрать DELAYED из запросов, при росте кол-ва тредов время будет расти (особенность MyISAM)
зависимость времени исполнения от кол-во одновременных тредов (1 тред на хост):
Hosts:1741 HostsPerProcess:1741 DataSources:882544
SYSTEM STATS: Time:49.3651 Method:spine Processes:1 Threads:16
SYSTEM STATS: Time:27.2454 Method:spine Processes:1 Threads:32
SYSTEM STATS: Time:23.7068 Method:spine Processes:1 Threads:40
SYSTEM STATS: Time:21.6130 Method:spine Processes:1 Threads:48
SYSTEM STATS: Time:19.5370 Method:spine Processes:1 Threads:64
Если убрать DELAYED из запросов, при росте кол-ва тредов время будет расти (особенность MyISAM)
у меня перед глазами пример, когда отложенная запись (INSERT DELAYED) на диск, расположенный в ОЗУ (memory-mapped экономит примерно 30% времени работы программы, которая снимает очень много данных (1M датчиков) с кучи коробок по SNMP.что с чем сравнивалось?
insert на ram vs insert delayed на ram?
вставка делалась через портянку строковых insert value или хитрее?
что с чем сравнивалось?insert на ram vs insert delayed на ram
Когда-то давно ещё смотрел MyISAM vs InnoDB vs MyISAM (row_format=FIXED). Последний с учетом работающих DELAYED рвет всех остальных.
вставка делалась через портянку строковых insert value или хитрее?длинные строковые insert'ы
Попутно встречал подобное решение MySQL + Postgres в интернете несколько раз, поэтому и считаю его правильным.использовались ли при этом InnoDB-таблицы или только MyISAM?
длинные строковые insert'ыmysql вставлять бинарными пакетами не умеет?
Насколько я знаю, не умеет.
Оставить комментарий
kataich
Здравствуйте,посоветуйте, пожалуйста, какую БД для хранения исторических данных лучше всего развернуть, удовлетворяющую
следующим условиям:
- хочется иметь возможность хранить данные с тиковой частотой на довольно больших
временных промежутках ( до 10 лет).
- быстрота работы при нагрузках (к примеру, каждую секунду происходит добавление/извлечение 200-300 новых/уже существующих элементов)
- возможность соединения со сторонними приложениями (C#)
- конечно, хотелось бы все бесплатно
Я смотрел в три стороны: mysql, mssql compact и kdb+. Читал мнения, что sql не очень подходит
для исторических данных. Но, вполне возможно, что я и не много прошу
Буду благодарен за советы практиков.