|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
Пока сидим на PostgreSQL но встают жуткие проблемы при проходе всей базы, апдейтах, выборках. Мы храним bitcoin blockchain распарсеный по блокам, транзакциям, входам и выходам и адресам. Почти по всем сущносятм делаются различные аналитические выборки, в то же время в режиме реального времени добавляются новые данные со скоростью примерно 200 тысяч транзакций в сутки, около 1.5M входов столько же выходов. Всего сейчас около 140М транзакций под 400М входов и выходов. При добавлении данных идет обсчет всех значений для к примеру адресов, сколько пришло сколько ушло и так далее. База с индексами весит почти 200 гигов. Вся БД на одном сервере с 64GB RAM (из которых используется только 10GB) и SSD жесктим диском, на котором только БД. При аналитических выборках по нашим алгоритмам это все выполняется очень долго. Хотелось бы иметь возможность выбирать любые данные по различным критериям не больше секунды. А так же проводить массовый апдейт. Думали на тему MemSQL, даже попробовали туда начать экспорт но все равно уперлись примерно в 10к операций в секунду, что для нас очень медленно, кроме того mysql движок наложил ограничения при массовых инсертах он не возвращает id как PostgrSQL что приводит к последующему селекту. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2016, 18:38 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
PS: Мы готовы рассмотреть вариант докупки до 5 серверов с SSD и 64GB RAM ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2016, 18:44 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
Извинясь за PS, не могу топик изменить что бы добавить данные. Нам обязательна нужна транзакционность и желательно что бы были нормальные клинеты так как разработка идет на Rails\Elixir и не хотелось бы проблем с сырыми клиентами. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2016, 18:49 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
nateless, Противоречивые у Вас требования - чтобы OLTP и OLAP сразу, да еще и бесплатно! Попробуйте Cache с ее системой онлайн аналитики DeepSee, если рассматриваете платные варианты. В московском представительстве InterSystems есть технические специалисты, рекомендую с ними пообщаться. Только сформулируйте задачу поаккуратнее:какие таблицы, колонки, ключи, количество записей в таблицах, количество пользователей, какие запросы, количество запросов на ввод, на запись и пр. А может, Вам в форум NoSQL, Big Data? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2016, 21:00 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
nateless, какие транзакции, какой риалтайм ? это все четкая противоположность концепции биг дата. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2016, 23:21 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
Стебелек сегодня зарелизился. Этот потянет. Но он в Бете, хоть и с транзакциями. Так что тут еще думать нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2016, 23:42 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
Yo.!nateless, какие транзакции, какой риалтайм ? это все четкая противоположность концепции биг дата. +1 либо ACID, либо RealTime :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2016, 09:44 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
У PostreSql есть возможность реплицирования. Что мешает OLTP использовать на одном сервере, а аналитику делать на другом? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2016, 10:36 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
Oracle 12.1.0.2 с inmemory option, даже без Real Application Clusters (RAC) с такими объёмом пойдёт... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2016, 15:36 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
может будет проще заменить SSD? ps но сначала лучше найти узкое место ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2016, 12:47 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
Yo.!nateless, какие транзакции, какой риалтайм ? это все четкая противоположность концепции биг дата. +1 При таких требованиях это не BigData, а ManyRows правильнее уж называть :) Мне кажется автору стоит не искать лекарство от всех болезней, оставить OLTP на Постгре + рядом поставить какой нибудь колонко-ориентированный сервер и периодически на него переносить изменения с OLTP. Если данных много и обновление хранилищ данных должно вести с высокой периодичностью, то можно и на MPP решения посмотреть. Смущают правда массовые апдейты. Для хранилищ данных это удар ниже пояса, тяжело апдейты отлавливать в первоисточниках, еще тяжелее их без потери прозрачности схемы данных и производительности в хранилище данных укладывать. Здесь наверное имеет смысл и на OLTP доделать добавление изменений данных во времени как новых записей, чтобы OLTP текущее состояние своих данных поддерживал на апдейтах, но вел историю изменений вставками для их последующего захвата хранилищем данных. А хранилище дальше может их преобразовывать на измерения, меняющиеся во времени и факты, в конечном счете раскладывая по витринам. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2016, 15:46 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
Как я понимаю для blockhain из ACID важно только: А и C. Атомарное и консистентное сохранение одного "документа" Посмотрите в сторону RethinkDB. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 14:58 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
DirksDR, Пока хотелось бы остаться на opensource решениях и компенсировать все колл серверов. Arm79, Логика наших апдейтов достаточно сложная кроме того сам блокчейн не так прост, в нем есть варианты сайд чейнов, когда майнеры майнят ветку которая потом будет признана не действительной и можно откатить до 6 блоков назад это огромный массив данных и тут либо писать сложную систему отката, либо проводить повторно наши обсчеты с какого-то save point`a. И это только одна из множества проблем. Поэтому думаем как оставить все в одном хранилие и не делать "холодную" / "горячую" базу. xtender, Подойдет как? Что Oracle может дать того что не дает PostgreSQL? Есть какие-то метрики которые скажут что мы получи X прирост производительность и у нас не будет проблем с постоянными адпейтами как архивных (старых) так и новых данных? ASCRUS, MPP это что? :) nikolay.kulikov@gmail.com, Смотрели скорость записи\чтения очень низкая. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 16:20 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
natelessЧто Oracle может дать того что не дает PostgreSQL? Понимание того, что все проблемы вы себе создаёте собственными кривыми руками. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 16:34 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
natelessПри аналитических выборках по нашим алгоритмам это все выполняется очень долго. Хотелось бы иметь возможность выбирать любые данные по различным критериям не больше секунды. IMHO Проще всего разнести рабочею БД и БД для аналитике по разным машинам. Если это действительно аналитика. natelessА так же проводить массовый апдейт. Не знаю,что под этими словами точно скрывается. Но обычно, в реальных системах, именно "массовый апдейт" требуется достаточно редко. Если частая операция - что то не то в Вашей структуре данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 17:13 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev, у них она не просто частая, а массовая по 20--30k версий -- как два байта об асфальт см тут: http://www.sql.ru/forum/1202248/ochen-dolgiy-update-na-30m-zapisey?mid=18859272#18859272 т.е. пж тут сосёт ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 17:19 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
По логике в Oracle с updte'ами и insert'ами должно быть намного полегче. Там даже vacum'ам нет, за ненадобностью ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 17:38 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
natelessЛогика наших апдейтов достаточно сложная кроме того сам блокчейн не так прост, в нем есть варианты сайд чейнов, когда майнеры майнят ветку которая потом будет признана не действительной и можно откатить до 6 блоков назад это огромный массив данных и тут либо писать сложную систему отката, либо проводить повторно наши обсчеты с какого-то save point`a. И это только одна из множества проблем. Поэтому думаем как оставить все в одном хранилие и не делать "холодную" / "горячую" базу. И что? Как это мешает репликации и разнесению нагрузки? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 17:47 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
nateless, На всякий случай. Как вариант решения железом "в лоб" - 2x E5-2667V3, 16x 32GB LRDIMM 2133MHz, 2x PCI-E SSD типа Intel P3700 серии объемом 400-800 ГБ. Можно и Р3600 серии, но это будет несколько медленнее и на чтение, и на запись. Тупо, железно, начнет тормозить со временем (по мере роста базы) - но на сейчас задачу решит, относительно близко к желаемым критериям. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 17:48 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
natelessxtender, Подойдет как? Что Oracle может дать того что не дает PostgreSQL? Есть какие-то метрики которые скажут что мы получи X прирост производительность и у нас не будет проблем с постоянными адпейтами как архивных (старых) так и новых данных?То есть вы даже не понимаете как работает PostgreSQL? В принципе уже дали частичный ответ: Leonid KudryavtsevПо логике в Oracle с updte'ами и insert'ами должно быть намного полегче. Там даже vacum'ам нет, за ненадобностью )))Помимо этого стоит еще добавить, что все будет еще быстрее с Inmemory option, за счет избавления от лишних индексов и векторной обработки: White paper: Oracle Database In-Memory In-Memory Acceleration for the Real-Time Enterprise Помимо этого, думаю еще надо правильно выбрать/продумать схемы секционирования для еще большего ускорения. И еще можно будет дополнительно ускорить с использованием Real Application Cluster(RAC) или хотя бы Active Standby: например, гонять аналитику на второй ноде или на стэндбае. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 18:23 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
xtender, К сожалению нет, я не DBA. Спасибо за инфу почитаю. Как я понял RAC уже в платном Оракле, какая там стоимость за год на сервер с 16 ядрами? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 18:28 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
nateless, имхо рано вам про обычный RAC думать, пока подумайте про RAC one node наверное. По поводу цен да и вообще миграции поговорите с самим Ораклом, я думаю сейлзы/пресейлзы продажи ради и анализ, и тесты вам проведут ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 18:33 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
natelessкакая там стоимость за год на сервер с 16 ядрами?там есть еще вариант и оплаты по NUP'ам, т.е. Named user plus ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 18:35 |
|
Посоветуйте СУБД под BigData с новыми данными в режиме риалтайм.
|
|||
---|---|---|---|
#18+
nateless, Virtuoso Open Source ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.03.2016, 19:32 |
|
|
start [/forum/topic.php?fid=35&msg=39195856&tid=1552279]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
59ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
others: | 15ms |
total: | 186ms |
0 / 0 |