Комментарии 242
Что делать когда место на диске кончится?
- Купить диск побольше?
- Купить ещё дисков?
- Удалить устаревшие данные?
4. Купить еще побольше дисков побольше
… и лучше заранее
… и лучше заранее
3. Удалить устаревшие данные?В системах хранения, основанных на журналировании, удаление данных ведёт не к освобождению места, а к дополнительным записям на диск, т.е. к уменьшению свободного места (если оставить в стороне создание снимков состояния, которое само по себе требует довольно больших объёмов свободного места).
sudo rm -rf /*
Полагаю периодически делается снимок состояния базы в памяти на диск, и лог транзакций чистится.
Место в памяти, нет?
Если кто-то действительно заинтересован разобраться в вопросе рекомендую:
В общем автор статьи делает упор на то, что БД в памяти просто быстрее работают, потому что пишут только в память, а она быстрее.
Так же делает упор, что в disk oriented DB, в плохом случае, при каждом чтении мы будет лезть на диск. Что подразумевает, что он сравнивает in-memory DB запущенную на PC при достаточным объемом памяти с disk oriented DB, у которой нет достаточно памяти, чтобы держать необходимые страницы в buffer pool.
- Lecture #02 — In-Memory Databases [CMU Database Systems Spring 2016] (весь курс хорош).
- OLTP Through the Looking Glass, and What We Found There (в лекции есть ссылка на эту статью о overhead, который существует в disk oriented DB, потому что они были реализованы под старую архитектуру).
В общем автор статьи делает упор на то, что БД в памяти просто быстрее работают, потому что пишут только в память, а она быстрее.
Так же делает упор, что в disk oriented DB, в плохом случае, при каждом чтении мы будет лезть на диск. Что подразумевает, что он сравнивает in-memory DB запущенную на PC при достаточным объемом памяти с disk oriented DB, у которой нет достаточно памяти, чтобы держать необходимые страницы в buffer pool.
Спасибо за ссылку на лекцию от CMU. В свою очередь могу порекомендовать материал аффилированный с SAP, но его стоит воспринимать только в качестве"концепта" в рамках БД в памяти — https://hpi.de/plattner/research/in-memory-data-management-for-enterprise-systems.html.
И ещё один отличный курс, уже от open.hpi, на ту же тему. Ведёт «сам» дядько Платтнер (один из основателей SAP-а). Все видео и слайды доступны «безвоздмездно и без СМС», т.е. даром. Рассказывается и про историю идеи, и про концепт, и про внутреннее устройство.
In-Memory Data Management 2015
https://open.hpi.de/courses/imdb2015
In-Memory Data Management 2015
https://open.hpi.de/courses/imdb2015
Отчасти. В вопросе чтения — согласен с вами. И тут про сравнение с дисковой СУБД с buffer pool будет отдельная статья. В вопросе записи — не согласен. Запись в дисковой СУБД идет в B/B+ дерево как ни крути. И это медленней чем запись последовательно в файл.
Я не совсем понимаю о чем мы тут говорим.
Насколько я понимаю in-memory db vs disk oriented dbs. Дисковые БД в большинстве случаев будут медленнее, чем in-memory. Даже в случае чтения, потому что нет overhead на buffer pool, по другому организованы locking & latching, а так же используется другая схема организации данных в памяти, другой concurrency control. Это как раз и дает хороший прирост производительности, даже для чтения.
Есть огромное количество in-memory Db, которые даже и не задумываются о durability, то есть совсем не пишут на диск.
В всех мне известных нормальных disk oriented БД так же происходит запись сначала в transaction log, что подразумевает под собой последовательную запись.
Насколько я понимаю in-memory db vs disk oriented dbs. Дисковые БД в большинстве случаев будут медленнее, чем in-memory. Даже в случае чтения, потому что нет overhead на buffer pool, по другому организованы locking & latching, а так же используется другая схема организации данных в памяти, другой concurrency control. Это как раз и дает хороший прирост производительности, даже для чтения.
Есть огромное количество in-memory Db, которые даже и не задумываются о durability, то есть совсем не пишут на диск.
В всех мне известных нормальных disk oriented БД так же происходит запись сначала в transaction log, что подразумевает под собой последовательную запись.
«Насколько я понимаю in-memory db vs disk oriented dbs. Дисковые БД в большинстве случаев будут медленнее, чем in-memory… » — на 100% согласен с этим абзацем!
«Есть огромное количество in-memory Db» — да! Но некоторые делают это и делают это правильно. Как делать это правильно — как раз написано в статье. Разумеется, по верхам, без деталей.
«В всех мне известных нормальных disk oriented БД так же происходит запись сначала в transaction log, что подразумевает под собой последовательную запись.» — Да. Но кроме этого запись происходит еще и в B/B+ дерево. И вот это есть рандомная запись на диск и это есть медленно.
«Есть огромное количество in-memory Db» — да! Но некоторые делают это и делают это правильно. Как делать это правильно — как раз написано в статье. Разумеется, по верхам, без деталей.
«В всех мне известных нормальных disk oriented БД так же происходит запись сначала в transaction log, что подразумевает под собой последовательную запись.» — Да. Но кроме этого запись происходит еще и в B/B+ дерево. И вот это есть рандомная запись на диск и это есть медленно.
> Как делать это правильно — как раз написано в статье.
Правильно? Просто писать transaction log? А после restart ждать вечность, пока индексы опять построятся и данные загружаться в память?
> И вот это есть рандомная запись на диск и это есть медленно.
Ну она не влияет на саму запись в БД, это все делается отдельным working thread, притом все это может batching.
Чтобы меня правильно поняли — я за эту статью, просто хотелось дополнить, так как верно замечено «Разумеется, по верхам, без деталей.». :)
Правильно? Просто писать transaction log? А после restart ждать вечность, пока индексы опять построятся и данные загружаться в память?
> И вот это есть рандомная запись на диск и это есть медленно.
Ну она не влияет на саму запись в БД, это все делается отдельным working thread, притом все это может batching.
Чтобы меня правильно поняли — я за эту статью, просто хотелось дополнить, так как верно замечено «Разумеется, по верхам, без деталей.». :)
«Правильно? Просто писать transaction log? А после restart ждать вечность, пока индексы опять построятся и данные загружаться в память? » — не совсем. Дочтите статью до конца. Там где про снимки состояния.
«Ну она не влияет на саму запись в БД, это все делается отдельным working thread, притом все это может batching.» — влияет, к сожалению. Потому что все что ушло в лог транзакций, но не записалось в дерево хранится в памяти. Рано или поздно эту память надо сбросить на диск в дерево. Механизма компактификации лога транзакций у дисковых СУБД нет (см. P.S. в моей статье про компактификацию лога транзакций), поэтому, чтобы восстановление не заняло вечности надо данные таки записать в дерево на диске, не дожидаясь даже пока кончится оперативная память. Упомянутый вами батчинг помогает лишь отчасти. Когда у вас идут случайные изменения строк в СУБД (это типичный workload), то батчи-не-батчи, все равно каждый батч надо распихать по разным частям дерева.
«Чтобы меня правильно поняли — я за эту статью, просто хотелось дополнить, так как верно замечено «Разумеется, по верхам, без деталей.». :)» Все верно :)
«Ну она не влияет на саму запись в БД, это все делается отдельным working thread, притом все это может batching.» — влияет, к сожалению. Потому что все что ушло в лог транзакций, но не записалось в дерево хранится в памяти. Рано или поздно эту память надо сбросить на диск в дерево. Механизма компактификации лога транзакций у дисковых СУБД нет (см. P.S. в моей статье про компактификацию лога транзакций), поэтому, чтобы восстановление не заняло вечности надо данные таки записать в дерево на диске, не дожидаясь даже пока кончится оперативная память. Упомянутый вами батчинг помогает лишь отчасти. Когда у вас идут случайные изменения строк в СУБД (это типичный workload), то батчи-не-батчи, все равно каждый батч надо распихать по разным частям дерева.
«Чтобы меня правильно поняли — я за эту статью, просто хотелось дополнить, так как верно замечено «Разумеется, по верхам, без деталей.». :)» Все верно :)
****************************************
Упомянутый вами батчинг помогает лишь отчасти. Когда у вас идут случайные изменения строк в СУБД (это типичный workload), то батчи-не-батчи, все равно каждый батч надо распихать по разным частям дерева.
********************************************
Это никак не влияет на время отклика.
По коммиту все не записанные данные из буфферного пула лога(память), пишутся ПОСЛЕДОВАТЕЛЬНО в лог-файл.
По завершению процесса клиенту сообщается о завершении commit(транзакции).
База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы.
Это может произойти довольно нескоро и делается это отдельным процессом-потоком.
И еще в дерево пишутся не кусочки информации, а страницы, по специальным алгоритмам, удерживающих в памяти часто используемую информацию.
Даже для отдельных таблиц можно указать приоритет удерживания их блоков в памяти.
Я к тому, что если в сервере есть много памяти, то при желании можно сделать из обычной базы почти In-memory…
Упомянутый вами батчинг помогает лишь отчасти. Когда у вас идут случайные изменения строк в СУБД (это типичный workload), то батчи-не-батчи, все равно каждый батч надо распихать по разным частям дерева.
********************************************
Это никак не влияет на время отклика.
По коммиту все не записанные данные из буфферного пула лога(память), пишутся ПОСЛЕДОВАТЕЛЬНО в лог-файл.
По завершению процесса клиенту сообщается о завершении commit(транзакции).
База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы.
Это может произойти довольно нескоро и делается это отдельным процессом-потоком.
И еще в дерево пишутся не кусочки информации, а страницы, по специальным алгоритмам, удерживающих в памяти часто используемую информацию.
Даже для отдельных таблиц можно указать приоритет удерживания их блоков в памяти.
Я к тому, что если в сервере есть много памяти, то при желании можно сделать из обычной базы почти In-memory…
«База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы. » — в общем случае это неверноу утверждение. Например, когда делается UPDATE, то надо подсчитать rows affected и вернуть это клиенту. Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row. Причем, это не только запись в индексы, но и чтение из индексов в перемешку. И все это с рандомным перемещением головки, потому что различные row и части индекса, которые изменяются, находятся в разных местах диска.
Если вся база целиком закэшированна в памяти, то это может дать гарантию, что вся информация, которая нужна, чтобы вернуть результат UPDATE (да и INSERT, кстати, тоже — ибо надо проверить на duplicate key), находится в кэше. Т.е. я частично с вами соглашусь — это закэшировать все целиком + иметь дополнительно ооочень много памяти, чтобы держать огромный write back буфер, то это будет чем-то похоже на in-memory.
Правда, будет все равно хуже чем in-memort:
1. Будет хуже по пропускной способности на запись, потому что рано или поздно надо записать данные в индексы рандомно. Страницы по специальным алгоритмам — это все равно рандомная запись страниц и это все равно не как у in-memory — полностью последовательный сброс снимка на диск, повторюсь еще раз, всегда при любых условиях, гарантрованно, последовательный.
2. Даже при наличие большого количества памяти нельзя хранить изменения в write back буферах вечно, потому что при старте тогда надо будет проиграть огромный накопившийся лог транзакций. И тут два варианта — или лог проигрывается всегда в память (забываем про табличное пространство и по сути держим всю базу в памяти, всегда проигрывая лог) или проигрывается при старте в табличное пространство. Оба варианта хуже чем in-memory. В первом варианте вам надо проигрывать огромный лог изменений vs снимок + небольшой лог изменений. Во втором варианте вам надо проиграть изменения не в память, а не диск и рандомно (изменения идут в случайном порядке, а не в таком, в каком бы вам хотелось и поэтому на диск в табличное пространство и индексы тоже применяется в случайном порядке).
3. Будет хуже по памяти, те понадобится больше памяти. Как минимум для write back буферов, которых у in-memory базы нет. И для кэша, потому что кэш — это структура данных оптимизированная под быстрое наполнение и освобождение, из-за чего жертвуется пространством. Например, если на диске страница с дырками, то и в кэше она с дыркам — чтобы быстрее читаться с диска без лишнего парсинга. Почитайте про устройства буферного пула в MySQL (InnoDB) тут: https://www.percona.com/files/percona-live/justin-innodb-internals.pdf и тут: https://michael.bouvy.net/blog/en/2015/01/18/understanding-mysql-innodb-buffer-pool-size/
Если вся база целиком закэшированна в памяти, то это может дать гарантию, что вся информация, которая нужна, чтобы вернуть результат UPDATE (да и INSERT, кстати, тоже — ибо надо проверить на duplicate key), находится в кэше. Т.е. я частично с вами соглашусь — это закэшировать все целиком + иметь дополнительно ооочень много памяти, чтобы держать огромный write back буфер, то это будет чем-то похоже на in-memory.
Правда, будет все равно хуже чем in-memort:
1. Будет хуже по пропускной способности на запись, потому что рано или поздно надо записать данные в индексы рандомно. Страницы по специальным алгоритмам — это все равно рандомная запись страниц и это все равно не как у in-memory — полностью последовательный сброс снимка на диск, повторюсь еще раз, всегда при любых условиях, гарантрованно, последовательный.
2. Даже при наличие большого количества памяти нельзя хранить изменения в write back буферах вечно, потому что при старте тогда надо будет проиграть огромный накопившийся лог транзакций. И тут два варианта — или лог проигрывается всегда в память (забываем про табличное пространство и по сути держим всю базу в памяти, всегда проигрывая лог) или проигрывается при старте в табличное пространство. Оба варианта хуже чем in-memory. В первом варианте вам надо проигрывать огромный лог изменений vs снимок + небольшой лог изменений. Во втором варианте вам надо проиграть изменения не в память, а не диск и рандомно (изменения идут в случайном порядке, а не в таком, в каком бы вам хотелось и поэтому на диск в табличное пространство и индексы тоже применяется в случайном порядке).
3. Будет хуже по памяти, те понадобится больше памяти. Как минимум для write back буферов, которых у in-memory базы нет. И для кэша, потому что кэш — это структура данных оптимизированная под быстрое наполнение и освобождение, из-за чего жертвуется пространством. Например, если на диске страница с дырками, то и в кэше она с дыркам — чтобы быстрее читаться с диска без лишнего парсинга. Почитайте про устройства буферного пула в MySQL (InnoDB) тут: https://www.percona.com/files/percona-live/justin-innodb-internals.pdf и тут: https://michael.bouvy.net/blog/en/2015/01/18/understanding-mysql-innodb-buffer-pool-size/
Например, когда делается UPDATE, то надо подсчитать rows affected и вернуть это клиенту. Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row
Это ещё зачем (исходим из того что все необходимые для запроса данные закешированы (повезло) и блокировка наложена успешно). Зачем ждать сброса грязных данных для ответа на update??? Строго говоря, тут и записи в REDO дожидаться не обязательно, транзакцию же не закрываем.
Если мы исходим из того, что повезло, то да, ждать не надо. Все будет хорошо. За исключением пп.1,2,3 выше.
В вашем утверждении «База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы. „ не было сказано, что повезло. Оно было сделано безусловно.
В вашем утверждении «База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы. „ не было сказано, что повезло. Оно было сделано безусловно.
+++++++++++++++++++++++++++++++
Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row.
++++++++++++++++++++++++++++++++++++++
Даже дальше читать не стал.
Я вам говорю как это есть в коммерческих СУБД, а не то, что вам представляется.
Изменения делаются только в буфере(в памяти) страниц(копии блоков таблиц и индексов в памяти).
Также делается запись в БУФЕР(память) лога.
По коммиту буфер лога сбрасывается в лог(redo write ahead).
ВСЁ — пользователю сообщается о успешном коммите.
Причем по коммиту сбрасываются данные не только своей транзакции, а всего что было до.
Если закешировать всю таблицу, то не потребуется и чтения блоков с диска при UPDATE.
А вот запись в датафайлы НИКАК не связана с временем отклика.
Это ассинхронный процесс для обеспечения чекпоинтов, которые будут использоваться при восстановлении и обеспечивают моменты времени в которые можно считать, что все блоки из памяти были записаны на диск(датафайлы).
Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row.
++++++++++++++++++++++++++++++++++++++
Даже дальше читать не стал.
Я вам говорю как это есть в коммерческих СУБД, а не то, что вам представляется.
Изменения делаются только в буфере(в памяти) страниц(копии блоков таблиц и индексов в памяти).
Также делается запись в БУФЕР(память) лога.
По коммиту буфер лога сбрасывается в лог(redo write ahead).
ВСЁ — пользователю сообщается о успешном коммите.
Причем по коммиту сбрасываются данные не только своей транзакции, а всего что было до.
Если закешировать всю таблицу, то не потребуется и чтения блоков с диска при UPDATE.
А вот запись в датафайлы НИКАК не связана с временем отклика.
Это ассинхронный процесс для обеспечения чекпоинтов, которые будут использоваться при восстановлении и обеспечивают моменты времени в которые можно считать, что все блоки из памяти были записаны на диск(датафайлы).
Если памяти хватает, чтобы хранить все грязные страницы всегда, тогда вы правы. Я придрался выше к тому, что в общем случае утверждение было неверно. Еще раз, если памяти хватает, то все хорошо. Но все равно будет работать медленнее чем in-memory и потреблять больше памяти, просто потому что in-memory заранее оптимизирована под работу, когда все всегда в памяти.
В каком общем случае?
Утверждение верно, почитайте про Write-ahead logging…
перед написанием следующей статьи, то что вы описали в статье всё точно также работает и в обычных базах. И запись в редо-лог и снапшоты(чекпоинты), нет только фазы загрузки базы в память на старте.
Вот этот ваш текст об обычных базах в корне не верен и заморочит не одну неокрепшую голову — «надо реально дождаться записи в табличное пространство»:
********************************************************
Breslavets
«База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы. »
danikin
— в общем случае это неверноу утверждение. Например, когда делается UPDATE, то надо подсчитать rows affected и вернуть это клиенту. Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row. Причем, это не только запись в индексы, но и чтение из индексов в перемешку. И все это с рандомным перемещением головки, потому что различные row и части индекса, которые изменяются, находятся в разных местах диска.
***********************************************************************
Утверждение верно, почитайте про Write-ahead logging…
перед написанием следующей статьи, то что вы описали в статье всё точно также работает и в обычных базах. И запись в редо-лог и снапшоты(чекпоинты), нет только фазы загрузки базы в память на старте.
Вот этот ваш текст об обычных базах в корне не верен и заморочит не одну неокрепшую голову — «надо реально дождаться записи в табличное пространство»:
********************************************************
Breslavets
«База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы. »
danikin
— в общем случае это неверноу утверждение. Например, когда делается UPDATE, то надо подсчитать rows affected и вернуть это клиенту. Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row. Причем, это не только запись в индексы, но и чтение из индексов в перемешку. И все это с рандомным перемещением головки, потому что различные row и части индекса, которые изменяются, находятся в разных местах диска.
***********************************************************************
Если есть труба, которая слева широкая, а справа — узкая и в нее втекает слева вода, заполняя все сечение трубы, то какая бы не была длинная эта труба, рано или поздно в нее будет втекать слева ровно столько воды сколько и вытекает справа. Т.е. узость трубы справа будет узким местом и будет влиять на количество воды, которое может втечь в нее в единицу времени слева.
Базе хошь-не-хошь придется дожидаться флаша грязных страниц на диск, потому что не будет хватать памяти, чтобы сохранять в ней грязные изменения. Если только, еще раз повторю, если только вся база целиком не закэширована в памяти. Т.е. в общем случае ваше утверждение остается неверным.
Базе хошь-не-хошь придется дожидаться флаша грязных страниц на диск, потому что не будет хватать памяти, чтобы сохранять в ней грязные изменения. Если только, еще раз повторю, если только вся база целиком не закэширована в памяти. Т.е. в общем случае ваше утверждение остается неверным.
типа выкрутились… :)
Этот текст уже правильный и сильно отличается от исходного, а то меня уже пугало,
что вы там собрались что-то писать про обычные базы.
Но огорчу, описанных проблем не возникает при как я писал адекватном железе, софте и админе. Чекпоинт плавненько идет не надрывая систему.
И тем не менее, то что вы написали можно отнести и к In-memory базам, когда им не хватит памяти…
Кроме того ждемс описания чудесато-шустрого процесса создания чекпоинта, т.е. снапшота.
Как это сделано в In-memory базе без рэндом записей?
Что весь кусок памяти(всю базу) на диск?
Но такое часто не поделаешь.
Этот текст уже правильный и сильно отличается от исходного, а то меня уже пугало,
что вы там собрались что-то писать про обычные базы.
Но огорчу, описанных проблем не возникает при как я писал адекватном железе, софте и админе. Чекпоинт плавненько идет не надрывая систему.
И тем не менее, то что вы написали можно отнести и к In-memory базам, когда им не хватит памяти…
Кроме того ждемс описания чудесато-шустрого процесса создания чекпоинта, т.е. снапшота.
Как это сделано в In-memory базе без рэндом записей?
Что весь кусок памяти(всю базу) на диск?
Но такое часто не поделаешь.
Повторюсь, не пытаюсь доказать, что из обычной базы можно сделать полный эквивалент базы в памяти.
Можно сделать «почти» в каком-то варианте.
Но читать заблуждения о обычных базах тоже не хочется.
Вам не надо спешить, в том числе и со статьями.
Можно сделать «почти» в каком-то варианте.
Но читать заблуждения о обычных базах тоже не хочется.
Вам не надо спешить, в том числе и со статьями.
Вы забыли добавить, что еще при адекватных пользователях, которые не создают нагрузку в 100K запросов в секунду :-)
Ибо, если пользователи не такие адекватные, то проблем не возникает только лишь при соответствующей настройке базы, чтобы она все грязные страница флашила путем последовательнорго обхода всей базы, чтобы не упираться в рандомную запись, а это значит, что пока она обходит должно быть место в памяти для хранения всех грязных страниц, что, в свою очередь, при равномерно распределенной нагрузке по всей базе почти неизбежно означает, что нужно в памяти хранить всю копию базы. Я этот тезив в том или ином виде повторяю уже Nый раз, и в ответ слышу лишь про магические хорошие настройки и тд без конкретнго объяснения физике процесса как узкая труба становится широкой.
in-memory базам хватает памяти. Они просто не работают, когда кончается память. Это не повод для гордости. Но это обратная строна медали, с которой надо мириться заранее при проектировании приложения. Ровно также как обычные базы перестают работать при нагрузке хотя бы 1/10 от in-memory баз, даже если все сидит в кэше. И с этим фактом тоже надо мириться заранее при проектировании приложения.
Вест кусок, да на диск. Описал тут в деталах в одном из коментов. И это можно делать часто, ибо это происходит линейно, диск не нагружая, оставляя много IOPS'ов для REDO.
Ибо, если пользователи не такие адекватные, то проблем не возникает только лишь при соответствующей настройке базы, чтобы она все грязные страница флашила путем последовательнорго обхода всей базы, чтобы не упираться в рандомную запись, а это значит, что пока она обходит должно быть место в памяти для хранения всех грязных страниц, что, в свою очередь, при равномерно распределенной нагрузке по всей базе почти неизбежно означает, что нужно в памяти хранить всю копию базы. Я этот тезив в том или ином виде повторяю уже Nый раз, и в ответ слышу лишь про магические хорошие настройки и тд без конкретнго объяснения физике процесса как узкая труба становится широкой.
in-memory базам хватает памяти. Они просто не работают, когда кончается память. Это не повод для гордости. Но это обратная строна медали, с которой надо мириться заранее при проектировании приложения. Ровно также как обычные базы перестают работать при нагрузке хотя бы 1/10 от in-memory баз, даже если все сидит в кэше. И с этим фактом тоже надо мириться заранее при проектировании приложения.
Вест кусок, да на диск. Описал тут в деталах в одном из коментов. И это можно делать часто, ибо это происходит линейно, диск не нагружая, оставляя много IOPS'ов для REDO.
*************************************
Ровно также как обычные базы перестают работать при нагрузке хотя бы 1/10 от in-memory баз, даже если все сидит в кэше. И с этим фактом тоже надо мириться заранее при проектировании приложения.
***************************************************
Ну для того их и придумали, в памяти…
Oracle и Oracle TimesTen In-Memory Database :)
Кому не надо такой скорости хватит и обычных СУБД.
Про пользователей не совсем понятно, но по кэшу вам любой админ скажет, что в разогретой базе процент попадания в кэш идет под 100%.(тут могут быть тонкости с этими процентами, но в целом...).
Т.е. они практически ин-мемори. :)
Ровно также как обычные базы перестают работать при нагрузке хотя бы 1/10 от in-memory баз, даже если все сидит в кэше. И с этим фактом тоже надо мириться заранее при проектировании приложения.
***************************************************
Ну для того их и придумали, в памяти…
Oracle и Oracle TimesTen In-Memory Database :)
Кому не надо такой скорости хватит и обычных СУБД.
Про пользователей не совсем понятно, но по кэшу вам любой админ скажет, что в разогретой базе процент попадания в кэш идет под 100%.(тут могут быть тонкости с этими процентами, но в целом...).
Т.е. они практически ин-мемори. :)
К утру сошлись на трех рублях :-)
В разогретой базе процент попадания в кэш высокий. Вопрос в том, как быстро работает это кэш версус ин-мемори база. Обычно хорошо, если в 10 раз медленнее, как я написал выше. Плюс его разгорев — это отдельная боль, я уже писал про это.
В разогретой базе процент попадания в кэш высокий. Вопрос в том, как быстро работает это кэш версус ин-мемори база. Обычно хорошо, если в 10 раз медленнее, как я написал выше. Плюс его разгорев — это отдельная боль, я уже писал про это.
Не туда подцепил ответ )
К утру сошлись на трех рублях :-)
В разогретой базе процент попадания в кэш высокий. Вопрос в том, как быстро работает это кэш версус ин-мемори база. Обычно хорошо, если в 10 раз медленнее, как я написал выше. Плюс его разгорев — это отдельная боль, я уже писал про это.
К утру сошлись на трех рублях :-)
В разогретой базе процент попадания в кэш высокий. Вопрос в том, как быстро работает это кэш версус ин-мемори база. Обычно хорошо, если в 10 раз медленнее, как я написал выше. Плюс его разгорев — это отдельная боль, я уже писал про это.
--Правда, будет все равно хуже чем in-memort:
Я не вдаюсь в детали и не утверждаю обратного.
Но отмечаю, что конкретный момент увязки времени отклика и завершения процесса записи информации в базу освещен не верно.
Тут только добавляется время чтения блоков, если их нет в кэше.
Но я специально оговорил, что мы рассматриваем закешированную таблицу/индексы.
Я не вдаюсь в детали и не утверждаю обратного.
Но отмечаю, что конкретный момент увязки времени отклика и завершения процесса записи информации в базу освещен не верно.
Тут только добавляется время чтения блоков, если их нет в кэше.
Но я специально оговорил, что мы рассматриваем закешированную таблицу/индексы.
Может быть ожидание контрольной точки.
См. мой комент выше. Если закэшировать вообще все и вся, то да.
Да вы так и не поняли про запись.
Вам пытаются сказать, что коммерческие СУБД делают изменения таблиц-индексов ВСЕГДА в кэше(в памяти).
Запись по коммиту ведется только в редо-логи.
И запись в табличные пространства не влияет на время отклика в любом случае, так как она производится для измененных блоков во всей базе (любыми транзакциями) асинхронно от конкретной транзакции, а не как вы считаете, специально для конкретной транзакции что-то пишется в табличные пространства по коммиту.
Мы конечно говорим про нормально настроенную базу с адекватным железом и админом.
Вам пытаются сказать, что коммерческие СУБД делают изменения таблиц-индексов ВСЕГДА в кэше(в памяти).
Запись по коммиту ведется только в редо-логи.
И запись в табличные пространства не влияет на время отклика в любом случае, так как она производится для измененных блоков во всей базе (любыми транзакциями) асинхронно от конкретной транзакции, а не как вы считаете, специально для конкретной транзакции что-то пишется в табличные пространства по коммиту.
Мы конечно говорим про нормально настроенную базу с адекватным железом и админом.
Кстати в статье запись тоже производится думаю примерно также и для тех же целей — то что в статье называется снимком(чистый чекпоинт в обычных базах).
Т.е. измененная информация даже в этих in-memory базах также пишется на диск в табличные пространства как и в обычных базах(независимо от комита в конкретной транзакции), иначе после перезагрузки не будет данных :).
В целом, по статье, я вижу отличие от обычных баз только в том, что при старте такой базы она полностью «восстанавливается» в память, ну и другие структуры — хотя это неправильный подход — на физическом уровне в обычных базах может быть что угодно.
В обычных базах мы можем указать таблицы, блоки которых хотим держать по возможности в памяти.
Т.е. измененная информация даже в этих in-memory базах также пишется на диск в табличные пространства как и в обычных базах(независимо от комита в конкретной транзакции), иначе после перезагрузки не будет данных :).
В целом, по статье, я вижу отличие от обычных баз только в том, что при старте такой базы она полностью «восстанавливается» в память, ну и другие структуры — хотя это неправильный подход — на физическом уровне в обычных базах может быть что угодно.
В обычных базах мы можем указать таблицы, блоки которых хотим держать по возможности в памяти.
Снимок можно делать реже или чаще — это никак не влияет на скорость работы IMDB. Это влияет только на скорость восстановления.
Насчет неправильного подхода — вопрос спорный. Вы можете настроить Oracle или вашу любимую классическую СУБД так, чтобы она заданные таблицы сразу на старте целиком загружала в память, вместе с индексами и с данными и никогда бы их из памяти не убирала и хранила бы их в памяти эффективно с точки зрения потребления памяти, а на также как эти данные представлены на диске? Если можете, то поделитесь, пожалуйста, настройками — я проведу бенчмарки на чтение таких таблиц. Если окажется, что они будут работать по скорости хотя бы рядом с IMDB, то я сниму перед ваши шляпу.
Насчет неправильного подхода — вопрос спорный. Вы можете настроить Oracle или вашу любимую классическую СУБД так, чтобы она заданные таблицы сразу на старте целиком загружала в память, вместе с индексами и с данными и никогда бы их из памяти не убирала и хранила бы их в памяти эффективно с точки зрения потребления памяти, а на также как эти данные представлены на диске? Если можете, то поделитесь, пожалуйста, настройками — я проведу бенчмарки на чтение таких таблиц. Если окажется, что они будут работать по скорости хотя бы рядом с IMDB, то я сниму перед ваши шляпу.
*****************************************
Снимок можно делать реже или чаще — это никак не влияет на скорость работы IMDB. Это влияет только на скорость восстановления.
**************************************************
Вот, в обычных системах точно также, особенно если вспомнить, что в IMDB может памяти не хватить.
Ну и опять же при условии адекватности софта-железа-админа :)
Конечно почти также, иначе не придумывали бы IMDB.
Может получиться, что процесс записи нагружает хранилище и
это может сказаться скорости чтений блоков.
Но всё должно быть сбалансировано под задачу.
Не понял про «неправильный» подход…
Я говорил о неправильном вашем понимании шагов, которые выполняет СУБД при DML+commit.
И всегда подчеркивал, что полную IMDB из обычной не сделаешь.
Все же от задачи зависит.
Я, например знаю систему, в которой использовали Oracle In-Memory, а потом поняли, что хватит и обычного Oracle.
Если база редко перегружается и правильно настроена, то необходимые блоки будут всегда «разогреты»(почти :) ).
Снимок можно делать реже или чаще — это никак не влияет на скорость работы IMDB. Это влияет только на скорость восстановления.
**************************************************
Вот, в обычных системах точно также, особенно если вспомнить, что в IMDB может памяти не хватить.
Ну и опять же при условии адекватности софта-железа-админа :)
Конечно почти также, иначе не придумывали бы IMDB.
Может получиться, что процесс записи нагружает хранилище и
это может сказаться скорости чтений блоков.
Но всё должно быть сбалансировано под задачу.
Не понял про «неправильный» подход…
Я говорил о неправильном вашем понимании шагов, которые выполняет СУБД при DML+commit.
И всегда подчеркивал, что полную IMDB из обычной не сделаешь.
Все же от задачи зависит.
Я, например знаю систему, в которой использовали Oracle In-Memory, а потом поняли, что хватит и обычного Oracle.
Если база редко перегружается и правильно настроена, то необходимые блоки будут всегда «разогреты»(почти :) ).
Перечитал про «неправильность» — ясно о чем…
Я там к тому, что выдвигать физические способы хранения-доступа на первый план не совсем корректно.
Есть обычные базы со своими запатентованными методами хранения-поиска…
Или, я например не уверен, что даже то же упомянутое LSM-дерево
не используется в каких-то обычных базах — почему нет?
В целом не эта рутина интересна и важна, если именно она конечно не решает проблемы, которые есть в обычных базах.
Я там к тому, что выдвигать физические способы хранения-доступа на первый план не совсем корректно.
Есть обычные базы со своими запатентованными методами хранения-поиска…
Или, я например не уверен, что даже то же упомянутое LSM-дерево
не используется в каких-то обычных базах — почему нет?
В целом не эта рутина интересна и важна, если именно она конечно не решает проблемы, которые есть в обычных базах.
Еще раз повторюсь. Если вся база влезла в кэш, то тогда все хорошо. В противном случае аналог снимка (флаг грязных страниц) будет не успевать отрабатывать целиком, пока будут приезжать новые грязные страницы, и в этот момент придется задерживать клтиента пока не завершится флаш. Если вы считаете, что не придется, то куда тогда будут применяться изменения, если память кончилась? Только в REDO?
Если у вас достаточно памяти, то да. Если недостаточно памяти, то асинхронный процесс в какой-то момент превратится в синхронный, потому что не будет памяти, чтобы сохранять в ней грязные страницы.
Перечитал еще раз, и увидел еще одно заблуждение по поводу обычных СУБД.
Даже не понял сначала с этой терминологией…
Снимки в IMDB — это аналоги чекпоинтов в обычных базах, ну и бакапы есть разных видов.
Память в адекватной системе не может кончится — специальный процесс постоянно следит за этим, выгружая наименее используемые блоки из кэша.
**************************************************************
Механизма компактификации лога транзакций у дисковых СУБД нет (см. P.S. в моей статье про компактификацию лога транзакций), поэтому, чтобы восстановление не заняло вечности надо данные таки записать в дерево на диске, не дожидаясь даже пока кончится оперативная память.
**********************************************************************
Не надо вам про обычные базы пока статью писать.
Лучше подробнее про IMDB рассказать.
Вот например, можно ли делать кластеры, что делать если потребуется увеличить размер базы.
Как это делается, растет и какие тут тонкости, чем платится и есть ли ограничения?
Даже не понял сначала с этой терминологией…
Снимки в IMDB — это аналоги чекпоинтов в обычных базах, ну и бакапы есть разных видов.
Память в адекватной системе не может кончится — специальный процесс постоянно следит за этим, выгружая наименее используемые блоки из кэша.
**************************************************************
Механизма компактификации лога транзакций у дисковых СУБД нет (см. P.S. в моей статье про компактификацию лога транзакций), поэтому, чтобы восстановление не заняло вечности надо данные таки записать в дерево на диске, не дожидаясь даже пока кончится оперативная память.
**********************************************************************
Не надо вам про обычные базы пока статью писать.
Лучше подробнее про IMDB рассказать.
Вот например, можно ли делать кластеры, что делать если потребуется увеличить размер базы.
Как это делается, растет и какие тут тонкости, чем платится и есть ли ограничения?
«выгружая наименее используемые блоки из кэша» — что приводит к рандомной записи на диск. Которой в IMDB нет.
«Механизма компактификации лога транзакций» — уже выше обсуждали, что тут неверно поняли друг друга, разное понимание терминалогии. Под компактификацией в IMDB понимается постоянный сброс полностью всего снимка всей базы данных, который снимает необходимость при восстановлении читать все логи, сделанные раньше снимка. Снимок всей базы у RDBMS не делается, потому что RDBMS не хранится вся в памяти.
«Не надо вам про обычные базы пока статью писать.» — это статья про IMDB. Но сравниваю с RDBMS. Чтобы было понятно тем кто сейчас на них сидит. Я понимаю, что тут сидят все профи по RDBMS. Вопрос только в том до каких нагрузок эти профи их разгоняли и во что эти профи упирались. Если вы на их нагрузках они ни во что не упирались, то не надо думать, что вы супер-профи и все про RDBMS знаете, все адекватно настроили и сидите на вершине мира, и не надо думать, что те, кто уже сидят на IMDB — полные мудаки и не пробовали различные варианты ускорить RDBMS прежде чем перейти на IMDB. Призываю вас сконцентрироваться на том, что для вас новое и познавать, вместо того, чтобы цепляться к каждой букве, строить неверные выводы и триумфировать на этом.
Теперь насчет кластеров. На моем опыте все делается на уровне приложения. Кластеризация на уровне СУБД (как это сделано в couchbase) приводит к излишним тормозам и головняку. Обыяно кластеризуем так, что разделяет разные независимые куски на разные базы и храним их на разных серверах. Рассказывать детали, чем платится и какие ограничения пока не хочу. Сначала все надо в более менее обоснованную статью выдать, сведя все факты, иначе вы выльете поток говна и троллинга, не разобравшись :-)
«Механизма компактификации лога транзакций» — уже выше обсуждали, что тут неверно поняли друг друга, разное понимание терминалогии. Под компактификацией в IMDB понимается постоянный сброс полностью всего снимка всей базы данных, который снимает необходимость при восстановлении читать все логи, сделанные раньше снимка. Снимок всей базы у RDBMS не делается, потому что RDBMS не хранится вся в памяти.
«Не надо вам про обычные базы пока статью писать.» — это статья про IMDB. Но сравниваю с RDBMS. Чтобы было понятно тем кто сейчас на них сидит. Я понимаю, что тут сидят все профи по RDBMS. Вопрос только в том до каких нагрузок эти профи их разгоняли и во что эти профи упирались. Если вы на их нагрузках они ни во что не упирались, то не надо думать, что вы супер-профи и все про RDBMS знаете, все адекватно настроили и сидите на вершине мира, и не надо думать, что те, кто уже сидят на IMDB — полные мудаки и не пробовали различные варианты ускорить RDBMS прежде чем перейти на IMDB. Призываю вас сконцентрироваться на том, что для вас новое и познавать, вместо того, чтобы цепляться к каждой букве, строить неверные выводы и триумфировать на этом.
Теперь насчет кластеров. На моем опыте все делается на уровне приложения. Кластеризация на уровне СУБД (как это сделано в couchbase) приводит к излишним тормозам и головняку. Обыяно кластеризуем так, что разделяет разные независимые куски на разные базы и храним их на разных серверах. Рассказывать детали, чем платится и какие ограничения пока не хочу. Сначала все надо в более менее обоснованную статью выдать, сведя все факты, иначе вы выльете поток говна и троллинга, не разобравшись :-)
«выгружая наименее используемые блоки из кэша» — что приводит к рандомной записи на диск. Которой в IMDB нет.
Как происходит «магия» «рандомной записи на диск. Которой в IMDB нет.» если по документации происходит работа с пачкой файлов ?!
Вы контролируете в какой сектор диска и что писать? Так вменяемые DB тоже это контролируют (в какое место внутри файла писать и когда)!
Согласно докам, все что Вы описали как «IMDB нет.» присутствует:
Tarantool’s disk-based storage engine is a fusion of ideas from modern filesystems, log-structured merge trees and classical B-trees. All data is organized into ranges. Each range is represented by a file on disk. Range size is a configuration option and normally is around 64MB. Each range is a collection of pages, serving different purposes. Pages in a fully merged range contain non-overlapping ranges of keys.
3.6.2. Vinyl features
- Separate storage formats: key-value (Default), or document (Keys are part of value)
- Versional database creation and asynchronous shutdown/drop
A scheduler assigns tasks to multiple background threads for transferring index data from memory to disk, and for reorganizing Runs. To support transactions, Set operations can be delayed until an explicit commit.
3.6.3.3. Inserting the next 200.000 keys
Several times, the in-memory index becomes too large and a Run Creation Thread transfers the keys to a Run. The Runs have been appended to the end of db file. The number of created Runs becomes large.
…
There is a user-settable maximum number of Runs per Range. When the number of Runs reaches this maximum, the vinyl scheduler wakes a Compaction Thread for the db file. The Compaction Thread merges the keys in all the Runs, and creates one or more new db files.
Now there are multiple pairs of in-memory indexes, and each pair has an associated db file. The combination of the in-memory indexes and the db file is called a Range, and the db file is called a Range File.
терзают смутные сомнения… :)
У Tarantool есть два движка — memtx (движок по умолчанию — in-memory) и vinyl (дополнительный, не in-memory движок, т.е. он не хранит все данные в памяти и предназначен для use cases, когда все данные в память не влезают).
Вы считаете, что Vinyl — это in-memory движок? Ну ок, продолжайте считать дальше. И на основании этого заблуждения стройте какие-угодно теории. Стройте, не буду вам мешать. Если вам это доставляет удовольствие :-)
Вы считаете, что Vinyl — это in-memory движок? Ну ок, продолжайте считать дальше. И на основании этого заблуждения стройте какие-угодно теории. Стройте, не буду вам мешать. Если вам это доставляет удовольствие :-)
Так они же вроде как в связке работают и один дополняет другой, или еще и тут «магия»?
Если Вы говорите исключительно о «in-memory storage engine (memtx)» тогда и для других DB включайте магию (Oracle «Oracle Database In-Memory», Sql Server «In-Memory OLTP» т.д.) говорите и сравнивайте только с аналогичными фичами «данных в памяти».
Если Вы говорите исключительно о «in-memory storage engine (memtx)» тогда и для других DB включайте магию (Oracle «Oracle Database In-Memory», Sql Server «In-Memory OLTP» т.д.) говорите и сравнивайте только с аналогичными фичами «данных в памяти».
«Так они же вроде как в связке работают и один дополняет другой, или еще и тут «магия»?» — не понял вашего вопроса, простите. Сформулируйте, плиз, по другому.
«Если Вы говорите исключительно о «in-memory storage engine (memtx)» тогда и для других DB включайте магию (Oracle «Oracle Database In-Memory», Sql Server «In-Memory OLTP» т.д.) » — какую магию, вы о чем?
«говорите и сравнивайте только с аналогичными фичами «данных в памяти».» — вы хотите, чтобы я в этой статье вместо того, что написал сравнил бы Tarantool с другими in-memory по их функциям? Мой ответ вам такой — менять эту статью на другую не буду. Эта статья конкретно про специфику IMDB в общем, а не про сравнение различных IMDB между собой. Сравнение Tarantool частично с Redis есть тут: https://habrahabr.ru/company/mailru/blog/317150/. Кроме того есть другое сравнение Tarantool с Redis вот тут https://hackernoon.com/tarantool-vs-redis-38a4041cc4bc#.yk5wxwdpx (написал внешний к Tarantool человек, там мой только перевод, ссылка на оригинал в тексте)
«Если Вы говорите исключительно о «in-memory storage engine (memtx)» тогда и для других DB включайте магию (Oracle «Oracle Database In-Memory», Sql Server «In-Memory OLTP» т.д.) » — какую магию, вы о чем?
«говорите и сравнивайте только с аналогичными фичами «данных в памяти».» — вы хотите, чтобы я в этой статье вместо того, что написал сравнил бы Tarantool с другими in-memory по их функциям? Мой ответ вам такой — менять эту статью на другую не буду. Эта статья конкретно про специфику IMDB в общем, а не про сравнение различных IMDB между собой. Сравнение Tarantool частично с Redis есть тут: https://habrahabr.ru/company/mailru/blog/317150/. Кроме того есть другое сравнение Tarantool с Redis вот тут https://hackernoon.com/tarantool-vs-redis-38a4041cc4bc#.yk5wxwdpx (написал внешний к Tarantool человек, там мой только перевод, ссылка на оригинал в тексте)
Можно ли заставить IMDB использовать только Vinyl или только Memtx в работе?
Когда вы приводите сравнение с «Обычной Базой Данных», то в этой «Обычной Базе Данных» слишком много проблем, по сравнению с IMDB. Основной акцент делается на «что приводит к рандомной записи на диск. Которой в IMDB нет.» и повторяется в разных вариантах.
Однако вам уже приводили примеры и ссылки, в которых «Обычные Базы Данных» отлично реализуют фунционал IMDB и это является одним из их штатных рабочих режимов. Да ладно… фиг с ним :)
Менять статью? зачем. Если не некоторые смущающие высказывания в ней и после нее, много людей бы не узнали бы любопытные подробности о этой теме:)
Так что спасибо :)
какую магию, вы о чем?
Когда вы приводите сравнение с «Обычной Базой Данных», то в этой «Обычной Базе Данных» слишком много проблем, по сравнению с IMDB. Основной акцент делается на «что приводит к рандомной записи на диск. Которой в IMDB нет.» и повторяется в разных вариантах.
Правда, будет все равно хуже чем in-memort:
1. Будет хуже по пропускной способности на запись, потому что рано или поздно надо записать данные в индексы рандомно.
Однако вам уже приводили примеры и ссылки, в которых «Обычные Базы Данных» отлично реализуют фунционал IMDB и это является одним из их штатных рабочих режимов. Да ладно… фиг с ним :)
Менять статью? зачем. Если не некоторые смущающие высказывания в ней и после нее, много людей бы не узнали бы любопытные подробности о этой теме:)
Так что спасибо :)
В IMDB рандомной записи, действительно, нет (и в частности в Memtx в Tarantool). В конкретно Vinyl ее тоже нет. Поэтому она тянет нагрузку на запись больше чем InnoDB от MySQL, например. Бенчи скоро покажем. Сам по себе Vinyl основан на LSM и фейсбучном RocksDB. Бенчи RocksDB вот тут: http://smalldatum.blogspot.ru/2016/01/rocksdb-vs-innodb-via-linkbench.html
Другой акцент, который я дела, что даже если все сидит в кэшах, то IMDB все равно быстрее RDBMS, просто потому что она заточена под быть всегда in-memory.
Про функционал я вообще в статье ни разу не говорил. Функционала у RDBMS больше чем у IMDB. И это одно из преимуществ RDBMS. Я тут только про производительность.
Вот именно. Я уж лучше переживу неадекватный троллинг, но дам людям новые знания.
Другой акцент, который я дела, что даже если все сидит в кэшах, то IMDB все равно быстрее RDBMS, просто потому что она заточена под быть всегда in-memory.
Однако вам уже приводили примеры и ссылки, в которых «Обычные Базы Данных» отлично реализуют фунционал IMDB и это является одним из их штатных рабочих режимов. Да ладно… фиг с ним :)
Про функционал я вообще в статье ни разу не говорил. Функционала у RDBMS больше чем у IMDB. И это одно из преимуществ RDBMS. Я тут только про производительность.
Менять статью? зачем. Если не некоторые смущающие высказывания в ней и после нее, много людей бы не узнали бы любопытные подробности о этой теме:)
Так что спасибо :)
Вот именно. Я уж лучше переживу неадекватный троллинг, но дам людям новые знания.
danikin
Призываю вас сконцентрироваться на том, что для вас новое и познавать, вместо того, чтобы цепляться к каждой букве, строить неверные выводы и триумфировать на этом.
Дык в том то и дело, что большая часть того, что вы почему-то считаете новым в статье, таковым не является для обычных СУБД.
Начиная с последовательной записи в редо(Write-ahead logging — капитан очевидность)…
Из статьи я узнал нового только использовании LMS Дерева в одной из версий IMDB.
О том, что база перед стартом грузится в память — это итак понятно было.
Вы собирались писать о обычных СУБД — было бы интересно сравнить
производительность на одинаковых задачах IMDB vs usual RDBMS.
С использолванием кэша по умолчанию, с захешированными данными…
danikin.
Я понимаю, что тут сидят все профи по RDBMS. Вопрос только в том до каких нагрузок эти профи их разгоняли и во что эти профи упирались. Если вы на их нагрузках они ни во что не упирались, то не надо думать, что вы супер-профи и все про RDBMS знаете, все адекватно настроили и сидите на вершине мира, и не надо думать, что те, кто уже сидят на IMDB — полные мудаки и не пробовали различные варианты ускорить RDBMS прежде чем перейти на IMDB. Призываю вас сконцентрироваться на том, что для вас новое и познавать, вместо того, чтобы цепляться к каждой букве, строить неверные выводы и триумфировать на этом
danikin
и не пробовали различные варианты ускорить RDBMS прежде чем перейти на IMDB.
Есть ощущение, что вы не особо пробовали обычные СУБД, ибо путаетесь в основах их устройства.
Тем не менее по-моему никто и не спорит о том, что IMDB имеет свою область применения.
Под вашу текущую задачу хорошо пошла IMDB — я так понял, что дешево и сердито. И пример хорош тем, что есть много таких задач(даже по объему если смотреть), где действительно нужно присмотреться к IMDB.
В то же время, на обычных СУБД работают очень высоко-нагруженные системы.
От биллинга в телекоммуникациях, до банковских и платежных систем с реально нешуточными нагрузками и объемами данных.
И поверьте, в этих системах денег особо не считают, надо было бы — использовали бы IMDB, если бы это было возможно(размеры баз, требования к downtime, надежности,...), и если бы это дало преимущества для бизнеса.
Вот этот ваш текст может быть истолкован неверно.
danikin
Механизма компактификации лога транзакций у дисковых СУБД нет
в терминологии IMDB — это чекпоинты в обычных базах.
После чекпоинта для горячего восстановления сбоя экземпляра
нужна только та часть лог-информации, что идет после этого чекпоинта.
Точно также как после снимка в IMDB не нужны старые журналы.
Тут их хранят(обычно на лентах) для возможного восстановления базы.
Сам процесс записи в табличные пространства не должен влиять на отклик в адекватной системе,
а процент попаданий при чтении(where ...) данных в кэш на горячих системах приближается к 100% — читай это IMDB.
danikin
Снимок всей базы у RDBMS не делается, потому что RDBMS не хранится вся в памяти.
Разные задачи, разные объемы,
Запись в датафайлы будет вестись даже при достаточном количестве памяти.
Старт базы будет быстрым.
Дык в том то и дело, что большая часть того, что вы почему-то считаете новым в статье, таковым не является для обычных СУБД.
Видимо, вы умеете читать мысли и знаете то, _что_я_считаю_новым_. Ок. Убеждать вас в обратном не вижу смысла, потому что вы лучше меня знаете, что я считаю, и что я не считаю :-)
Из статьи я узнал нового только использовании LMS Дерева в одной из версий IMDB.
Ну хотя бы в чем-то получили профит. Я рад.
Вы собирались писать о обычных СУБД — было бы интересно сравнить
производительность на одинаковых задачах IMDB vs usual RDBMS.
С использолванием кэша по умолчанию, с захешированными данными…
Уже писал выше, что напишу. И уже писал выше, что IMDB по моему опыту быстрее в десятки раз даже в этом случае. Не верите — проверьте, ну или ждите статьи.
Есть ощущение, что вы не особо пробовали обычные СУБД, ибо путаетесь в основах их устройства.
Не буду спорить с вашим ощущением. У меня тоже есть ощущение, что вы не пробовали обычные СУБД на нагрузках под 1000 транзакций в СЕКУНДУ и никогда не упирались в их потолок. Но я лучше оставлю его при себе.
От биллинга в телекоммуникациях, до банковских и платежных систем с реально нешуточными нагрузками и объемами данных.
Вы бы цифры привели. Я лично участвовал в разработке биллинга для МТС и других операторов задолго до работы в Mail.Ru. Там Oracle был окружен сапописной in-memory, чтобы справляться с нагрузкой. Beeline переходит уже на Tarantool (почитайте новости в Интернете). Сбербанк переводит свой процессинг на in-memory СУБД GridGain — почитайте тоже новости в Интернете. Я, вообще, предлагаю вылезли вам из ощущения мира, каким он был 20 лет назад. Он, не поверите, сильно поменялся с точки зрения нагрузок на СУБД и с точки зрения требованиям к latency.
И поверьте, в этих системах денег особо не считают, надо было бы — использовали бы IMDB, если бы это было возможно(размеры баз, требования к downtime, надежности,...), и если бы это дало преимущества для бизнеса.
Уже используют. См. выше. То, что вы не в курсе — не означает, что этого нет.
в терминологии IMDB — это чекпоинты в обычных базах.
После чекпоинта для горячего восстановления сбоя экземпляра
нужна только та часть лог-информации, что идет после этого чекпоинта.
Точно также как после снимка в IMDB не нужны старые журналы.
Тут их хранят(обычно на лентах) для возможного восстановления базы.
Сам процесс записи в табличные пространства не должен влиять на отклик в адекватной системе,
а процент попаданий при чтении(where ...) данных в кэш на горячих системах приближается к 100% — читай это IMDB.
Вот, пожалуй, единственное утверждение, с которым не хочется спорить. Все верно сказали :-)
Запись в датафайлы будет вестись даже при достаточном количестве памяти.
Старт базы будет быстрым.
Если бы вы использовали обычные СУБД на тех нагрузках, где IMDB вообще даже не начинают напрягаться (10К+ запросов в секунду), то вы бы поняли, что они начинают трещать по швам. И старт у них медленных, ибо нагрузка на холодную базу в 10K+ запросов в секунду убивает ее в щи.
danikin
Я лично участвовал в разработке биллинга для МТС и других операторов задолго до работы в Mail.Ru. Там Oracle был окружен сапописной in-memory, чтобы справляться с нагрузкой.
Давным давно был СБОС, без всяких оберток.
Базы-обертки-кэши используют довольно часто, при этом ВСЯ информация всё равно хранится в обычных базах.
И основная часть кода работает с обычными базами.
Потому что этого достаточно и с обычными базами кодить привычнее.:)
Кроме того они имеют отлаженную систему резервирования, а этот рынок очень консервативен.
danikin
Beeline переходит уже на Tarantool (почитайте новости в Интернете).
Дык вот когда перейдут, тогда и поаплодируем уходу от «ораклов».
Интересно, как там «звонки» будут они хранить в IMDB и сколько такая база будет стартовать?
Так обычно не делают, и дальше обертки на входе системы IMDB не пускают.
Т.е. только критичный к производительности модуль заводят на эту промежуточную базу… например те же звонки можно, но только текущая обработка на входе, а потом перемещение в основную базу обработанной информации.
Ибо IMDB быстренько лопнет по памяти от такого потока.
Или есть секретный рецепт?
danikin
Сбербанк переводит свой процессинг на in-memory СУБД GridGain
Аналогично, переведет, посмотрим…
Всё переведут, или как вы писали выше — «Там Oracle был окружен сапописной in-memory»…
danikin
Уже используют. См. выше. То, что вы не в курсе — не означает, что этого нет.
Вы точнее формулируйте — уже хотят использовать…
Или используют на приеме, в какой-то части системы, в качестве быстрого буфера… — да это уже давно в работе, и скорее всего в этом виде и останется в большинстве критичных к хранению данных проектов.
Я бы подобные вопросы ставил не так, что какая-то контора(банк, билайн...) переводит систему на IMDB, а разработчик соответствующего софта переходит на IMDB.
Или еще точнее начинает дополнительно использовать IMDB в какой-то части системы.
Потому что сам банк или сотовая компания ничего не могут сами поменять.
Вот чей биллинг использует сейчас Билайн?
Как они могут просто базу поменять, если в Тарантуле, как я понял нет даже нормальной поддержки SQL.
Скорее всего поменяют ту «обертку» на критичной по нагрузке части.
Как это и есть сейчас в подобных проектах.
danikin
Я, вообще, предлагаю вылезли вам из ощущения мира, каким он был 20 лет назад. Он, не поверите, сильно поменялся с точки зрения нагрузок на СУБД и с точки зрения требованиям к latency.
Вылезти?
Пока везде основной объем информации хранят Oracle и прочие… «тарантулы» только в проектах или на критичной к performance части только на входе для текущей обработки…
Я вот помню также активно вылезали в объектно-ориентированные базы…
Преподнося их как что-то новое на фоне реляционных…
Да так активно пиарили, что казалось уже завтра Oracle нигде не будет. :)
Давным давно был СБОС, без всяких оберток.
Угу. А еще давнее (еще до СБОСа) биллингов не было, и компьютеров не было.
Базы-обертки-кэши используют довольно часто, при этом ВСЯ информация всё равно хранится в обычных базах.
Прям ВСЯ и у ВСЕХ во ВСЕХ кейсах? Зуб даете?
И основная часть кода работает с обычными базами.
Потому что этого достаточно и с обычными базами кодить привычнее.:)
Да. Работает — не трожь.
Кроме того они имеют отлаженную систему резервирования, а этот рынок очень консервативен.
IMDB тоже имеют. Но рынок консервативный, спору нет.
Да.
Интересно, как там «звонки» будут они хранить в IMDB и сколько такая база будет стартовать?
А сколько у Билайна звонков в сутки? И сколько весит у них один CDR? И что, для биллинга надо все звонки за сутки хранить?
Так обычно не делают, и дальше обертки на входе системы IMDB не пускают.
Вас дезинформировали. Делают по разному.
Т.е. только критичный к производительности модуль заводят на эту промежуточную базу… например те же звонки можно, но только текущая обработка на входе, а потом перемещение в основную базу обработанной информации.
По началу Билайн так и будет делать. А потом задастся вопросом — а зачем мне основная база-то?
Ибо IMDB быстренько лопнет по памяти от такого потока.
Вам вангой надо работать.
Или есть секретный рецепт?
Будем секреты по чуть-чуть выдавать. Не все сразу.
Аналогично, переведет, посмотрим…
Всё переведут, или как вы писали выше — «Там Oracle был окружен сапописной in-memory»…
Сделают так, как это будет эффективней Самоцели заменять Оракл на что-то еще — ни у кого нет. Есть экономика и развитие бизнеса.
Вы точнее формулируйте — уже хотят использовать…
Или используют на приеме, в какой-то части системы, в качестве быстрого буфера… — да это уже давно в работе, и скорее всего в этом виде и останется в большинстве критичных к хранению данных проектов.
Ну точно ванга.
Потому что сам банк или сотовая компания ничего не могут сами поменять.
Прям ни один банк и ни одна сотовая компания сами прямо НИЧЕГО не могут поменять? Что за бред.
Вот чей биллинг использует сейчас Билайн?
Как они могут просто базу поменять, если в Тарантуле, как я понял нет даже нормальной поддержки SQL.
Скорее всего поменяют ту «обертку» на критичной по нагрузке части.
Как это и есть сейчас в подобных проектах.
Пока Tarantool будет оберткой, потом репликой, а там посмотрим.
Пока везде основной объем информации хранят Oracle и прочие… «тарантулы» только в проектах или на критичной к performance части только на входе для текущей обработки…
Прям таки ВЕЗДЕ? Я завидую вашей осводомленности обо ВСЕМ и обо ВСЕХ.
М-да… столько букв..., я тут и Ванга, и зуб должен давать… и телепат…
Почитал, в новостях есть что-то о использовании Тарантула в личном кабинете.
Это как-бы далеко не биллинг.
Заодно почитал, что Вымпелком меняет биллинг Amdocs, на систему от Ericsson… — и где, ёлы-палы там будет Тарантул?
Амдокс, кстати, итак использует IMDB с незапамятных времен для тарификации( сейчас IMDB+IMDG чтобы масштабируемость обеспечить), но звонки всё равно хранятся в обычной базе…
Вопрос ставить надо не о сутках, а о месяцах.
2 месяца, 6ть…
Разве клиент не может попросить/(заказать ежемесячно) детализацию по счету?
Или, что счета никому не надо выставлять в конце месяца с агрегацией по логическим вызовам(локальные, междугородние, международные, ...) скидки считать не надо....?
Плюс есть гос. требования к времени хранения.
Вы же вроде как говорили, что участвовали в разработке биллинга для МТС и еще нескольких операторов или тоже личные кабинеты были?
Бред?
Ну вы жжете.
Базу может поменять разработчик биллинга/банковской системы в какой-то из своих версий и предложить эту версию кастомеру.
И это не простая задача даже при смене полноценных RDBMS с полной поддержкой SQL, всё требует проверки и сертификации.
Даже при смене одной и той же базы на более старшую версию в четвертой цифре (11.2.0.2->11.2.0.4) вопросы будут, а уж если первые менять…
Конечно, Заказчик может поменять поставщика биллинга, но это опять же не просто смена базы.
Тут тема исчерпана похоже, почитаю как снимки делаются.
Хочу отметить, что тема мне интересна, и прошу не воспринимать какие-то
прямые ответы как наезд, раз уж опубликовали статью — варитесь — вкуснее будете.
Beeline переходит уже на Tarantool (почитайте новости в Интернете).
Почитал, в новостях есть что-то о использовании Тарантула в личном кабинете.
Это как-бы далеко не биллинг.
Заодно почитал, что Вымпелком меняет биллинг Amdocs, на систему от Ericsson… — и где, ёлы-палы там будет Тарантул?
Амдокс, кстати, итак использует IMDB с незапамятных времен для тарификации( сейчас IMDB+IMDG чтобы масштабируемость обеспечить), но звонки всё равно хранятся в обычной базе…
А сколько у Билайна звонков в сутки? И сколько весит у них один CDR? И что, для биллинга надо все звонки за сутки хранить?
Вопрос ставить надо не о сутках, а о месяцах.
2 месяца, 6ть…
Разве клиент не может попросить/(заказать ежемесячно) детализацию по счету?
Или, что счета никому не надо выставлять в конце месяца с агрегацией по логическим вызовам(локальные, междугородние, международные, ...) скидки считать не надо....?
Плюс есть гос. требования к времени хранения.
Вы же вроде как говорили, что участвовали в разработке биллинга для МТС и еще нескольких операторов или тоже личные кабинеты были?
Прям ни один банк и ни одна сотовая компания сами прямо НИЧЕГО не могут поменять? Что за бред.
Бред?
Ну вы жжете.
Базу может поменять разработчик биллинга/банковской системы в какой-то из своих версий и предложить эту версию кастомеру.
И это не простая задача даже при смене полноценных RDBMS с полной поддержкой SQL, всё требует проверки и сертификации.
Даже при смене одной и той же базы на более старшую версию в четвертой цифре (11.2.0.2->11.2.0.4) вопросы будут, а уж если первые менять…
Конечно, Заказчик может поменять поставщика биллинга, но это опять же не просто смена базы.
Тут тема исчерпана похоже, почитаю как снимки делаются.
Хочу отметить, что тема мне интересна, и прошу не воспринимать какие-то
прямые ответы как наезд, раз уж опубликовали статью — варитесь — вкуснее будете.
Заодно почитал, что Вымпелком меняет биллинг Amdocs, на систему от Ericsson… — и где, ёлы-палы там будет Тарантул?
Не все сразу
Разве клиент не может попросить/(заказать ежемесячно) детализацию по счету?
Или, что счета никому не надо выставлять в конце месяца с агрегацией по логическим вызовам(локальные, междугородние, международные, ...) скидки считать не надо....?
Разве нельзя исторические данные, на которые почти нет нагрузки, хранить в RDBMS? Можно. Одно другому-то не мешает.
Вы же вроде как говорили, что участвовали в разработке биллинга для МТС и еще нескольких операторов или тоже личные кабинеты были?
Мне не очень понятно ваше пренебрежительное отношение к личным кабинетам. Но я участвовал именно в разработке биллинга в СиБОССе. Писал штуку, которая называлась «Сервер оценки разговоров». Она хранила все в памяти, считала на лету сколько списать, отправляла в онлайне на коммутатор (через Radius, насколько я помню) инфу, сколько можно продолжаться разговор и записывала результат в Oracle. Кстати, в Oracle она писала не синхронно, иначе он не тянул, несмотря на то, что работал на огромных дорогих железках и быстрых дисках, поэтому и баланс абонента (тот который он получал при звонке в кол-центр или на USSD сообщение) обновлялся не синхронно, а несколько секунд спустя, когда Oracle все коммитил. Причем, скажу больше, не просто не синхронно, а еще и многопоточно во много параллельных коннектов, ибо через один коннект Oracle справлялся хуже чем через несколько.
Хочу отметить, что тема мне интересна, и прошу не воспринимать какие-то
прямые ответы как наезд, раз уж опубликовали статью — варитесь — вкуснее будете.
Что я и делаю. Готов слушать любой троллинг, наезды и неадекват, лишь бы за этой щелухой хотя бы иногда проглядывало драгоценое зерно истины и знаний :-)
НЛО прилетело и опубликовало эту надпись здесь
Мне не очень понятно ваше пренебрежительное отношение к личным кабинетам. Но я участвовал именно в разработке биллинга в СиБОССе.
Это не пренебрежение, просто народ был введен в заблуждение.
Личный кабинет — это личный кабинет, а биллинг — это совсем другая сложность и стоимость — сами почитайте в Сети, с Эриксоном на $1млрд. контракт заключили на 7 лет.
До этого с Амдокс был не хилый контракт.
Причем когда я сказал, что Заказчик не может просто так поменять базу в биллинге/банковской системе, с вашей стороны опять был поток, скажем так, недобросовестной мысли.
И я не знаю чего тут больше, — незнание того как такие системы сопровождаются или просто было желание закидать шапками,
объявив бредом невозможность замены базы заказчиком.
До этого вы рассуждали о Тарантул-обертке именно в контексте биллинга для Билайна на первое время,… цитировать не буду, но речь там шла именно о биллинге, о звонках в IMDB.
В общем не здорово всё это, и надеюсь вы понимаете, что в существующую систему биллинга воткнуть что-то чужеродное, тем более такое своеобразное как Тарантул силами Заказчика невозможно. А поставщику биллингга это вообще никак не нужно — у него итак используются работа в памяти в онлайн-чарчинг системах, и IMDB и IMDG в текущих версиях(т.е. могли предложить обновить систему....).
Совсем другое дело личный кабинет.
Писал штуку, которая называлась «Сервер оценки разговоров». Она хранила все в памяти, считала на лету сколько списать, отправляла в онлайне на коммутатор (через Radius, насколько я помню) инфу, сколько можно продолжаться разговор и записывала результат в Oracle.
prepaid, Онлайн тарификация, они(СБОСС) её делали позже основной своей постпайд системы…
И ключевое тут по теме —
«Она хранила все в памяти»…
и
«записывала результат в Oracle»…
Также как это делается в других подобных системах.
Спрашивается и чего мы тут буяним? :)
Кстати, в Oracle она писала не синхронно, иначе он не тянул, несмотря на то, что работал на огромных дорогих железках и быстрых дисках, поэтому и баланс абонента (тот который он получал при звонке в кол-центр или на USSD сообщение) обновлялся не синхронно, а несколько секунд спустя, когда Oracle все коммитил. Причем, скажу больше, не просто не синхронно, а еще и многопоточно во много параллельных коннектов, ибо через один коннект Oracle справлялся хуже чем через несколько.
На винде приложение писали(Visual C++) как основной их тарификатор?
У СБОСС проблема в том, что используется ОДНА база на ВСЁ.
Т.е. звонки, платежи(банк-касса), клиентская информация, абоненты-услуги, тарифы, начисления, роуминговая информация, номерная емкость, ежемесячная биллинговая информация(счета),… вообще ВСЁ хранится в одной базе. Ладно хранится, оно же всё время дергает базу в разные стороны…
Тогда как в подобных системах только для звонков должна быть возможность использования нескольких баз. То что я говорил о адекватности софта-железа-админа…
Не знаю делали ли они отдельную базу для prepaid — не думаю.
Хотя для большинства не очень больших операторов их postpaid система удобна и проста. Как и BIS питерский.
Пропускаю все что вы написали про мои недобросовесные мысли и про то, что заказчик не может поменять и все остальное про IMDB. У вас есть безусловно опыт тут. Странно, что вы его обобщаете на все и вся. Но это ваше дело :-)
Есть такая способность у многих людей, начинать спорить по одному вопросу, потом не закрыв первый переходить ко второму, потом приписывать другой стороне спора несуществующие аргументы и открывать по ним третий спор.
Но конкретно про СиБОСС. Вот там был а-ля Тарантул. Только самописный. Т.е., если бы они принимали сейчас решение о IMDB, то могли бы легко рассмотреть Тарантул с разработкой логики оценки разговоров на Lua внутри оного и с чтением/записью из/в Оракла прямо изнутри Тарантула + с персистенсом всех промежуточных результатов оценки, чтобы не перезагружать все из Оракла на рестарте. Я там работал, я знаю эту архитектуру. Я знаю архитектуру Тарантула. Это дает мне основания полагать, что он там подходит. У Билайна кейс пока другой, но в эту сторону они тоже могут в теории пойти, я не могу всего вам тут рассказать.
Да. Кажется, callcharge.exe назывался
Отлично. Вы сразу сотню high class разработчиков Oracle и DBA обвинили в некомпетентности. Как легко вы это делаете. Просто пипец )))
А ну как разнесите все на несколько баз в их конкретном кейса и чтобы ACID не потерять и чтобы не прийти к перегону кучи трафика между ними.
prepaid, Онлайн тарификация, они(СБОСС) её делали позже основной своей постпайд системы…
И ключевое тут по теме —
«Она хранила все в памяти»…
и
«записывала результат в Oracle»…
Также как это делается в других подобных системах.
Спрашивается и чего мы тут буяним? :)
Есть такая способность у многих людей, начинать спорить по одному вопросу, потом не закрыв первый переходить ко второму, потом приписывать другой стороне спора несуществующие аргументы и открывать по ним третий спор.
Но конкретно про СиБОСС. Вот там был а-ля Тарантул. Только самописный. Т.е., если бы они принимали сейчас решение о IMDB, то могли бы легко рассмотреть Тарантул с разработкой логики оценки разговоров на Lua внутри оного и с чтением/записью из/в Оракла прямо изнутри Тарантула + с персистенсом всех промежуточных результатов оценки, чтобы не перезагружать все из Оракла на рестарте. Я там работал, я знаю эту архитектуру. Я знаю архитектуру Тарантула. Это дает мне основания полагать, что он там подходит. У Билайна кейс пока другой, но в эту сторону они тоже могут в теории пойти, я не могу всего вам тут рассказать.
На винде приложение писали(Visual C++) как основной их тарификатор?
Да. Кажется, callcharge.exe назывался
У СБОСС проблема в том, что используется ОДНА база на ВСЁ.
Т.е. звонки, платежи(банк-касса), клиентская информация, абоненты-услуги, тарифы, начисления, роуминговая информация, номерная емкость, ежемесячная биллинговая информация(счета),… вообще ВСЁ хранится в одной базе. Ладно хранится, оно же всё время дергает базу в разные стороны…
Тогда как в подобных системах только для звонков должна быть возможность использования нескольких баз. То что я говорил о адекватности софта-железа-админа…
Не знаю делали ли они отдельную базу для prepaid — не думаю.
Отлично. Вы сразу сотню high class разработчиков Oracle и DBA обвинили в некомпетентности. Как легко вы это делаете. Просто пипец )))
А ну как разнесите все на несколько баз в их конкретном кейса и чтобы ACID не потерять и чтобы не прийти к перегону кучи трафика между ними.
Пропускаю все что вы написали про мои недобросовесные мысли и про то, что заказчик не может поменять и все остальное про IMDB.
Вы же заявили на весь свет, что Билайн меняет базу на Тарантула.
С вашей стороны это было совсем нескромное обобщение…
И я же еще и обобщаю что-то.
Отлично. Вы сразу сотню high class разработчиков Oracle и DBA обвинили в некомпетентности. Как легко вы это делаете. Просто пипец )))
А ну как разнесите все на несколько баз в их конкретном кейса и чтобы ACID не потерять и чтобы не прийти к перегону кучи трафика между ними.
Ну да, не просто, но может поэтому другие системы и стоят дороже и рынок другой имеют?
Думаете «водафоны» всё держат в одной базе?
У RDBMS итак проблем с масштабированием хватает, и при таком подходе они усугубляются.
Но повторюсь, для большинства российских операторов системы адекватны и
гораздо удобнее сложных в сопровождении западных систем.
Своеобразности хватает в обоих системах(СБОСС-БИС), например, по каким-то религиозным соображениям в СБОСС вообще не использовались внешние ключи.
Как я понял кто-то из топовых разрабов имел проблемы с блокировками и решил, что проще отказаться от FK, чем разбираться в проблеме.
Причем даже просто попытка поговорить на эту тему вызывала конкретный праведный гнев у одного из них. :)
Видимо крепко декларативная ссылочная целостность кого-то из них огрела.
Нет смысла это обсуждать в этой теме…
Вы же заявили на весь свет, что Билайн меняет базу на Тарантула.
С вашей стороны это было совсем нескромное обобщение…
И я же еще и обобщаю что-то.
Цитату можно?
Насчет СиБОСС и всего, что вы написали ниже — кто-то масштабирует базу, кто-то окружает ее IMDB-решениями. Говорить, что одно заведомо лучше чем другое — мне кажется, слишком… эм… серьезное обобщение.
Цитату можно?
Ну вы конечно мастрер общения…
Вот цитата, вы пишите, что в МТС биллинг был окружен самописной IMDB, и тут же добавляете, что Билайн переходит на Тарантула.
Речь о биллинге, не?
«переходит на Тарантула» <> «меняет базу на Тарантула»?
Ну давайте скажите что-нибудь про Вангу или про то, что меня дезинформировали или что у вас там еще в арсенале?
Breslavets
В то же время, на обычных СУБД работают очень высоко-нагруженные системы.
От биллинга в телекоммуникациях, до банковских и платежных систем с реально нешуточными нагрузками и объемами данных.
danikin
Вы бы цифры привели. Я лично участвовал в разработке биллинга для МТС и других операторов задолго до работы в Mail.Ru.
Там Oracle был окружен сапописной in-memory, чтобы справляться с нагрузкой. Beeline переходит уже на Tarantool (почитайте новости в Интернете).
кто-то масштабирует базу, кто-то окружает ее IMDB-решениями. Говорить, что одно заведомо лучше чем другое — мне кажется, слишком… эм… серьезное обобщение.
Давайте закруглятся, нормального общения у нас не выходит.
Тут никто не говорил, что IMDB не имеют своей ниши.
В биллинге используют НЕ однy базу(как минимум отдельные базы для звонков — это вроде просто понять?) + IMDB+IMDG для масштабирования на нагрузочной части(тарификация).
ВСЕ данные всё равно как правило хранят в обычных СУБД по множеству причин.
IMDB не поможет если весь биллинг, вся функциональность(контракты, клиенты, платежи, диллеры, проведение ежемесячного биллинга, звонки, роуминг, ...) свалена в одну RDBMS на серьезных объемах, даже на средних придётся с бубном плясать когда какие-то процессы пересекутся…
Ну вы конечно мастрер общения…
Вот цитата, вы пишите, что в МТС биллинг был окружен самописной IMDB, и тут же добавляете, что Билайн переходит на Тарантула.
Речь о биллинге, не?
«переходит на Тарантула» <> «меняет базу на Тарантула»?
Билайн переходит. Пока не Биллинг. Но это только начало.
Давайте закругляться, Ок :-)
Но конкретно про СиБОСС. Вот там был а-ля Тарантул. Только самописный. Т.е., если бы они принимали сейчас решение о IMDB, то могли бы легко рассмотреть Тарантул с разработкой логики оценки разговоров на Lua внутри оного и с чтением/записью из/в Оракла прямо изнутри Тарантула + с персистенсом всех промежуточных результатов оценки, чтобы не перезагружать все из Оракла на рестарте. Я там работал, я знаю эту архитектуру. Я знаю архитектуру Тарантула. Это дает мне основания полагать, что он там подходит. У Билайна кейс пока другой, но в эту сторону они тоже могут в теории пойти, я не могу всего вам тут рассказать.
Да не в этом дело, что подходит…
Устал уже говорить, что это давно используется в других системах.
И на место тарантула можно выбрать кучу кандидатов.
Проблема в том, что они уже были выбраны давно в системах о которых шла речь.
Устал уже говорить, что это давно используется в других системах.
Ну и отлично. IMDB это хорошо, даже в составе Биллинга. Что раньше, если я правильно понял коллег из этого чата, отрицалось намертво. Простите, если я неверно понял.
И на место тарантула можно выбрать кучу кандидатов.
Конечно.
Проблема в том, что они уже были выбраны давно в системах о которых шла речь.
Ну да.
Ну и отлично. IMDB это хорошо, даже в составе Биллинга. Что раньше, если я правильно понял коллег из этого чата, отрицалось намертво. Простите, если я неверно понял.
Все тут говорили, что где надо там они(IMDB ) и используются, но все данные как правило всё равно хранятся в обычных СУБД, — что вызывало у вас… В том же Билайне, если они покупали(не знаю точно) онлайн тарификацию — есть база в памяти, хотя у них древняя версия системы.
Очень интересно, что им там Эриксон наворотит и чем это закончится.
Часто сталкиваюсь с утверждениями, что «Ведь дисковая база данных вся влазит в in-memory кэш, зачем тогда нужны in-memory базы данных вообще; это хайп и маркетинг, всё давно изобретено в тёплых ламповых RDBMS». Для того чтобы парировать это некорректное утверждение, лекция №2 из курса CMU (первая ссылка), на мой взгляд, дает на сегодня самый полноценный и аргументированный ответ.
Корректный ответ состоит в том, что дисковые базы данных не плохие или хорошие сами по себе. Однако, они предназачены для работы с блоковым устройством хранения (block-storage device), коим является SSD и HDD. И это их классовое структурное ограничение. Имено поэтому, даже если вы дадите дисковой базе данных RAM-диск (тем самым потеряв вообще всякую персистентность), заметно быстрее она от этого работать не станет.
Вот скриншот по мотивам работы Стоунбрейкера «OLTP Through the Looking Glass» (слайд из лекции CMU, я думаю что не надо объяснять апологетам дисковых баз данных, кто такой Стоунбрейкер):
Слайд показывает, что дисковая база данных выполняет собственно полезную работу 12% времени, остальное время она, по сути, ворочает блоками.
Вот мои выдержки из лекции (дословно повторяю за автором лекций, Энди Павло, дабы не было повода думать, что это какие-то мои личные выдумки — Энди Павло явно более авторитетный источник чем я, достаточно посмотреть его биографию):
Корректный ответ состоит в том, что дисковые базы данных не плохие или хорошие сами по себе. Однако, они предназачены для работы с блоковым устройством хранения (block-storage device), коим является SSD и HDD. И это их классовое структурное ограничение. Имено поэтому, даже если вы дадите дисковой базе данных RAM-диск (тем самым потеряв вообще всякую персистентность), заметно быстрее она от этого работать не станет.
Вот скриншот по мотивам работы Стоунбрейкера «OLTP Through the Looking Glass» (слайд из лекции CMU, я думаю что не надо объяснять апологетам дисковых баз данных, кто такой Стоунбрейкер):
Слайд показывает, что дисковая база данных выполняет собственно полезную работу 12% времени, остальное время она, по сути, ворочает блоками.
Вот мои выдержки из лекции (дословно повторяю за автором лекций, Энди Павло, дабы не было повода думать, что это какие-то мои личные выдумки — Энди Павло явно более авторитетный источник чем я, достаточно посмотреть его биографию):
Why not use traditional disk-oriented DB with large enough cache? IMDB are completely designed from the ground-up for in-memory execution. Disk-based: block-oriented device, 4K blocks. Fetches blocks. Buffer pool manager as a cache. Manage movement of data back and forth between block-storage device and buffer pool. IMDB doesn’t have a buffer pool. Buffer pool manager is the differentiator. If you run 100 Gb RAM for a DB of 10 Gb, MySQL will never know that we will never run out of RAM – it is built in such a way that it will always do locking, latching, swizzling, buffer load etc. Then, in transaction management: disk-oriented system assumes any time trxn accesses the tuple, it might not be in memory and going to be able to stall, getting space for a new tuple. Interleaving stalls leads to locks and latches, locks are kept in a separate data structure (to avoid page faults). Actually modifying the tuples, traversing indices, executing queries – “OLTP through a looking glass”. Buffer pool 30%, lock manager 30%, recovery manager 28%. 12% is for actual useful work.
НЛО прилетело и опубликовало эту надпись здесь
А можно посмотреть реальные тесты, на основании которых построена эта (безусловно красивая) диаграмма? Нет, я не против того, что именно такой порядок цифр имеет место, просто хочется убедиться, что они взяты не с потолка. Кроме того, немного смущает сосредоточенность этой диаграммы на CPU. Это конечно важный ресурс, но не единственный. Хотелось бы ориентироваться на время выполнения, а не на утилизацию процессора.
Не можно, нужно: http://nms.csail.mit.edu/~stavros/pubs/OLTP_sigmod08.pdf (ссылка из верхнего — не моего — комментария). Кстати, настаиваю не я, а автор всего этого мувмента — Стоунбрейкер (который, например, автор того, что сейчас является PostgreSQL; просто товарищ очень активный и не стоит на месте, просто наслажлаясь уже имеющимися результатами своего труда).
All experiments are performed on a single-core Pentium 4 3.2GHz, with 1MB L2 cache, hyperthreading disabled, 1GB RAM, running Linux 2.6
ну что сказать — актуально :)
Согласен с вами, актуально! В какой-то мере ядрышко в тестах из статьи иногда даже помощнее, чем типичные ядра, что сегодня имеются в commodity машинах. У рабочей лошадки Skylake i7-6700k даже L2 cache такой же, как у Pentium 4. Или вы предлагаете тезис, что современные процессоры значительно лучше в сравнении с Pentium 4 для дисковых баз данных? Понятно, что многоядерность опять же сильно более полезна для in-memory баз данных, нежели для дисковых. А что такого уникального именно для дисковых?
ну запихайте imdb в такой же конфиг. запустите на нем такой же сценарий: 32 таблицы по миллиону записей. 1000 клиентов натравите случайным образом выбирать, удалять, обновлять, добавлять в одной из 32 таблицы.
покажите цифры по imdb и DiskDB. тогда будет предметный разговор, когда построим такие-же графики.
А пока все по принципу:
— давай рельсу возьмем?
— а зачем?
— если устанем, рельсу бросим и побежим очень быстро.
IMDB: лог транзакций на диск пишет? да. свое состояние сливает на диск? да. дисковые операции асинхронные? да. индексы и данные в памяти хранит? да. синхронизация между серверами есть? да.
DiskDB: лог транзакций на диск пишет? да. свое состояние сливает на диск? да. дисковые операции асинхронные? да. индексы и данные в памяти хранит? да. синхронизация между серверами есть? да.
Только с кого-то фига, дисковые операции для IMDB «бесплатны», а для DiskDB — прямо дибилы писали, которые только-только с дерева слезли и хвосты у них еще не отпали.
покажите цифры по imdb и DiskDB. тогда будет предметный разговор, когда построим такие-же графики.
А пока все по принципу:
— давай рельсу возьмем?
— а зачем?
— если устанем, рельсу бросим и побежим очень быстро.
IMDB: лог транзакций на диск пишет? да. свое состояние сливает на диск? да. дисковые операции асинхронные? да. индексы и данные в памяти хранит? да. синхронизация между серверами есть? да.
DiskDB: лог транзакций на диск пишет? да. свое состояние сливает на диск? да. дисковые операции асинхронные? да. индексы и данные в памяти хранит? да. синхронизация между серверами есть? да.
Только с кого-то фига, дисковые операции для IMDB «бесплатны», а для DiskDB — прямо дибилы писали, которые только-только с дерева слезли и хвосты у них еще не отпали.
Спасибо за наводку с вопросами, — видимо, я не смогу избежать подготовки статьи по мотивам CMU лекции. Соль в том, как DDB оперирует блоками (как работает буферный пул) и к чему это приводит в сравнении с IMDB. Это нетривиальное объяснение, оно не вписывается в один абзац, нужны картинки.
Тянет на статью :) Но как только это станет понятно (и все DDB так устроены) — странет понятно, о чём весь сыр-бор. Это общий принцип, которому следуют все DDB. И он, конечно, вовсе в корне не о том, что диск ворочает головкой. Это физическая особенность железа. SSD не ворочает головкой, но ситуация там тоже не сахар для DDB. Недавно на хабре была статья, где SQL Server разгоняли суперсовременным NAND сервером в TPC-тестах, добились прироста… +35%. Ну это, как бы, даже не разы. То есть, вовсе не в железе дело, а в принципе работы баз.
На самом деле, легко подобрать нагрузку, где в IMDB диск станет узким горлышком. Проблема в том, что у DDB эта граница — тысячи транзакций, у IMDB — миллионы.
Тянет на статью :) Но как только это станет понятно (и все DDB так устроены) — странет понятно, о чём весь сыр-бор. Это общий принцип, которому следуют все DDB. И он, конечно, вовсе в корне не о том, что диск ворочает головкой. Это физическая особенность железа. SSD не ворочает головкой, но ситуация там тоже не сахар для DDB. Недавно на хабре была статья, где SQL Server разгоняли суперсовременным NAND сервером в TPC-тестах, добились прироста… +35%. Ну это, как бы, даже не разы. То есть, вовсе не в железе дело, а в принципе работы баз.
На самом деле, легко подобрать нагрузку, где в IMDB диск станет узким горлышком. Проблема в том, что у DDB эта граница — тысячи транзакций, у IMDB — миллионы.
Очевидно, что Тарантул и прочие IMDB тоже не глупые люди писали, очевидно по каким-то мотивам и явно сравнивали свой результат с тем «что сделали до нас» что бы подтвердить свое решение.
Именно в этом «сравнение в сопоставимых режимах и одинаковых тестовых сценариях» и есть самое интересное. Много будет вам благодарных за такую статью.
Если Вы об этой статье, то там не +35% а поболее.
Смотря что смотрели:
Именно в этом «сравнение в сопоставимых режимах и одинаковых тестовых сценариях» и есть самое интересное. Много будет вам благодарных за такую статью.
Если Вы об этой статье, то там не +35% а поболее.
Смотря что смотрели:
Если сравнивать сценарий со временем задержки в 20 мс, то конфигурация с SSD-накопителями увеличила количество транзакций в 7,7 раз.
…
это дало преимущество в 10,1 раз по сравнению с HDD-накопителями, а в конфигурации с 24 базами и четырьмя экземплярами SQL Server получили прирост в 10,5 раз.
НЛО прилетело и опубликовало эту надпись здесь
Tarantool целиком в оперативке. Философия этих решений такова: даже если вы хотя бы допускаете возможность вытеснения на диск (дополнительные переключение контекстов, вход в режим ядра, I/O) дизайне движка, это будет уже другой класс решений, у которого максимальная производительность будет ниже в сравнении с решениями, где вытеснения нет.
Спасибо, дельный документ. Правда не нашёл там именно этой красивой круговой диаграммы, но это не беда. В документе много других, ещё более красивых. Собственно, я уже говорил, что никто не спорит с тем, что у IMDB меньше издержек по управлению данными. Особенно если поотключать логи и отказаться от многопоточности со всякими летчами. Но даже если не отключать. IMDB быстрее. Именно поэтому Oracle встроил её в 12 версию. Oracle Exadata вообще вся на IMDB-ячейках построена. Стоит конечно всё это безобразие дорого.
Есть тонкости. Отключаем логи — это уже, считай, memcached. В redis, к примеру, лог асинхронный — пишется на диск каждую секунду. В общем, это уже не полноценные замены DiskDB. В Oracle 12c, как я понимаю, встроено in-memory option — не является IMDB как таковой, но является прозрачным колоночно-организованным кешем, который поддерживается в памяти параллельно с основным построчным дисковым хранилищем. Их же TimesTen является полноценной IMDB и, вообще говоря, другой продукт. Есть ещё гибридные решения типа SAP HANA — там row и column одновременно без копий данных, интересное устройство само по себе, которого пока нет у других производителей.
Является. Туда TimesTen встроена. В Oracle Exadata и Oracle Exalytics, точно, в качестве своеобразного кэша. Скорее всего и в Oracle 12 тоже. Поколоночное сжатие тоже используется. В общем-то для того они TimesTen и купили, чтобы встроить в базу.
Прикольно, не обновлял эти знания пару лет. Действительно, немного запутанно: Applications with existing data residing in an Oracle Database can utilize the combination of the Oracle Database and TimesTen through the Oracle In-Memory Database Cache database option (as distinct from Oracle Database In-Memory), in which TimesTen functions as an in-memory cache database in front of an Oracle Database.
Это подавался как один из криериев :) Весьма весомый
Но, не очень понятно как можно сравнивать продукты предназначенные для разных сценариев работы в специфических сценариях игнорируя другие критерии.
Если сравниваться, то по всем критериям и желательно с цифрами (вроде все технические люди).Например: По объему обрабатываемых данных, по отказоустойчивость, «цена» каждой операции в одинаковых сценариях, по масштабируемости и т.д. А когда не могут внятно объяснить минусы описываемого решения, преподнося его как «Серебряную пулю», это… как-то «не закончено» выглядит :)
Но, не очень понятно как можно сравнивать продукты предназначенные для разных сценариев работы в специфических сценариях игнорируя другие критерии.
Если сравниваться, то по всем критериям и желательно с цифрами (вроде все технические люди).Например: По объему обрабатываемых данных, по отказоустойчивость, «цена» каждой операции в одинаковых сценариях, по масштабируемости и т.д. А когда не могут внятно объяснить минусы описываемого решения, преподнося его как «Серебряную пулю», это… как-то «не закончено» выглядит :)
Эти минусы, кстати, будут нивелированы новым железом. Например, NVM 3d-xpoint от Интел (в DIMM-формфакторе уже в 2017-м году) — это плашки постоянной (неволатильной) памяти объёмом 3 Тб штука, со скоростью чтения порядка DRAM, записи — раз в 5-10 медленнее DRAM. Эта память также является byte-addressable, как и DRAM. То есть, базы данных, ориентированные на block-storage, становятся как бы всё менее актуальными. Через пять лет такое железо будет в рамках нормы уже, и дисковые базы данных совсем отойдут. В стратегии Интел — принести вычисления ближе к данным, минимизируя число слоёв: вместо двух слоёв — постоянного диска и непостоянной памяти — будет просто постоянная память, и её будет много. Блоковые устройства становятся уделом чисто архивных данных.
Но ведь существует вероятность того, что БД ответит об успешном выполнении транзакции, в то время как сама транзакция еще не успеет записаться в файл, и в этот момент БД упадет/упадет сервер?
Последовательность действий такая:
1) СУБД получила запрос;
2) СУБД прочитала данные из RAM, выставила в RAM нужные блокировки и записала транзакцию в журнал;
3а) СУБД сообщила о выполнении транзакции;
3б) СУБД изменила данные в RAM и сняла блокировки.
Пункты 3а и 3б можно выполнять параллельно.
В какой момент что-то там упадёт?
1) СУБД получила запрос;
2) СУБД прочитала данные из RAM, выставила в RAM нужные блокировки и записала транзакцию в журнал;
3а) СУБД сообщила о выполнении транзакции;
3б) СУБД изменила данные в RAM и сняла блокировки.
Пункты 3а и 3б можно выполнять параллельно.
В какой момент что-то там упадёт?
Понял. Суть в том, что БД отвечает о выполнении транзакции только после фактический записи в журнал. В этом случае да, надежно, но время выполнения транзакции увеличивается до окончания записи на диск.
Журнал пишется строго последовательно, желательно большими блоками. Это быстро, очень быстро.
В тексте статьи было ясно сказано, что у СУБД есть две работы: это «запись транзакций в журнал» и «внесение изменений в БД».
Запись транзакций в журнал производится так: Сначала транзакции (от разных клиентов) накапливаются в памяти. Потом (или по ходу дела) для накопленных транзакций ставятся блокировки. Затем накопленные транзакции большим блоком пишутся в журнал. И это блок пишется непрерывным куском, поэтому пишется быстро.
Тут есть тонкость: нельзя накапливать транзакции, которые конфликтуют по блокировкам с более ранними ещё не выполненными транзакциями. Точнее, накапливать их можно, но в отдельной очереди. Тут всё сложно, я затрудняюсь точно сформулировать. Короче, у нас есть ограничение на размер единого блока, который мы пишем в журнал транзакций.
Но в любом случае, запись в журнал транзакций намного быстрее, чем внесение изменений в БД, расположенную на HDD.
Запись транзакций в журнал производится так: Сначала транзакции (от разных клиентов) накапливаются в памяти. Потом (или по ходу дела) для накопленных транзакций ставятся блокировки. Затем накопленные транзакции большим блоком пишутся в журнал. И это блок пишется непрерывным куском, поэтому пишется быстро.
Тут есть тонкость: нельзя накапливать транзакции, которые конфликтуют по блокировкам с более ранними ещё не выполненными транзакциями. Точнее, накапливать их можно, но в отдельной очереди. Тут всё сложно, я затрудняюсь точно сформулировать. Короче, у нас есть ограничение на размер единого блока, который мы пишем в журнал транзакций.
Но в любом случае, запись в журнал транзакций намного быстрее, чем внесение изменений в БД, расположенную на HDD.
запись транзакции в сотню байт на hdd проходит даже не на линейной скорости, а быстрее, на грани скорости шины sata, а точнее на скорости работы оперативной памяти кеша, пока он не будет заполнен, но при линейной записи он будет очищаться как раз на скорости линейной записи (т.е. если замерять время записи — оно будет минимальна, до тех пор, пока скорость очистки кеша будет быстрее или равна скорости его заполнения)
сама же запись в кеш на диске безопасна — при выключении она успеет записаться (за исключением ситуации с бедблоками)
сама же запись в кеш на диске безопасна — при выключении она успеет записаться (за исключением ситуации с бедблоками)
СУБД не отвечает пока не запишет данные в REDO. Если забыть о всяких новомодных async commit-ах.
Начали за здравие, кончили за упокой.
Ну и скромно обходится вниманием вопрос: как быть если данные в оперативную память не лезут? Да, да, можно разнести на разные хосты. А можно писать на диск. Всё от задачи зависит.
А так статья хорошая, годная.
давайте ненадолго забудем про кеширование, это тема для отдельной статьиКак это «забудем»? Кэш — это главное, что есть в традиционных СУБД! Всё же сказанное относительно быстрой записи в REDO остаётся в силе. Именно поэтому его выносят на отдельный диск, а то и на SSD.
Недостатком этого дерева является необходимость изменять его при каждом меняющем данные запросеВсё так, только не файл изменять а 1-2 страницы, опять же, скорее всего, закэшированные (не буду я про кэш забывать, что ещё за глупость?).
Ну и скромно обходится вниманием вопрос: как быть если данные в оперативную память не лезут? Да, да, можно разнести на разные хосты. А можно писать на диск. Всё от задачи зависит.
А так статья хорошая, годная.
Кэш — это, на самом деле зло. Такое же зло как и наркотик. Хорошо, когда он есть и плохо, когда он кончается, но ты уже подсел. И про это тоже будет отдельная статья. Достаточно сказать вловосочетание «холодный старт», от которого у бывалых админов шевелятся седые волосы на всех местах.
«Всё так, только не файл изменять а 1-2 страницы» — да. И для этого надо сделать несколько рандомных чтений и записей на диск.
«Всё так, только не файл изменять а 1-2 страницы, опять же, скорее всего, закэшированные» — и? как закэшированность страниц ускоряет их запись?
«Ну и скромно обходится вниманием вопрос: как быть если данные в оперативную память не лезут? Да, да, можно разнести на разные хосты. А можно писать на диск. Всё от задачи зависит.» — и это тоже тема отдельной статьи. Хотите все в одну кучу? Сорри, я так не умею. Скажу тут лишь то, что если данные не лезут в RAM, то надо понять, а что мы от них хотим, от данных этих, быстрой обработки или медленной. Если быстрой, то хошь не хошь надо покупать RAM и разносить на разные сервера, тк диск медленный. Если не хотим быстрой, то унести эти данные в обычную СУБД. Зачем использовать микроспоп для заколачивания гвоздей?
«А так статья хорошая, годная.» — согласен на все 100! :-)
«Всё так, только не файл изменять а 1-2 страницы» — да. И для этого надо сделать несколько рандомных чтений и записей на диск.
«Всё так, только не файл изменять а 1-2 страницы, опять же, скорее всего, закэшированные» — и? как закэшированность страниц ускоряет их запись?
«Ну и скромно обходится вниманием вопрос: как быть если данные в оперативную память не лезут? Да, да, можно разнести на разные хосты. А можно писать на диск. Всё от задачи зависит.» — и это тоже тема отдельной статьи. Хотите все в одну кучу? Сорри, я так не умею. Скажу тут лишь то, что если данные не лезут в RAM, то надо понять, а что мы от них хотим, от данных этих, быстрой обработки или медленной. Если быстрой, то хошь не хошь надо покупать RAM и разносить на разные сервера, тк диск медленный. Если не хотим быстрой, то унести эти данные в обычную СУБД. Зачем использовать микроспоп для заколачивания гвоздей?
«А так статья хорошая, годная.» — согласен на все 100! :-)
«БД в RAM» предполагает, что RAM достаточно велика, чтобы вместить всю БД. В этом случае вся БД будет закэширована.
Холодный старт для «БД в RAM» будет намного ужаснее, чем для обычной СУБД. Просто потому, что надо прочесть всю БД из последнего дампа и потом накатить на неё транзакции.
Кстати, дампы БД на диск — тоже не дешёвое удовольствие.
Холодный старт для «БД в RAM» будет намного ужаснее, чем для обычной СУБД. Просто потому, что надо прочесть всю БД из последнего дампа и потом накатить на неё транзакции.
Кстати, дампы БД на диск — тоже не дешёвое удовольствие.
Да не слишком намного. TimesTen, например нормально стартует. За вполне приемлемое время.
Вот про это тоже надо делать отдельную статью :) Комментирую тезисно
1. Холодный старт для БД в RAM происходит гораздо быстрее чем для обычной СУБД, потому что БД в RAM все данные читает, необходимые для горячей работы читает последовательно с диска (логи и снэпшоты), а обычная СУБД этого не делает, она просто стартует сразу и далее прогревается пользовательскими запросами, которые бьют в случайные части файлов на диске. По нашему опыту прогрев, скажем, Tarantool идет со скоростью 60-100Mb/s, прогрев MySQL — 2Mb/s. Соответственно, 64Gb памяти будут залиты в случае Tarantool 6-10 минут, а в случае MySQL за 9 часов. Это адок для продакшн-системы.
2. Надо отдать должное обычным СУБД — они работают сразу после старта, без прогрева. In-memory СУБД пока не загрузят вся в память целиком, не работают. Это, кстати, не сложно пофиксить. Достаточно снэпшот хранить в виде B/B+ дерева,. В этом случае на старте зачитывается только кусок лога после последнего снжпшота и далее запросы на данные, которые не загружены еще в память отдаются с диска с примерно такой же скоростью, с которой они отдаются в случае не прогретой дисковой СУБД. Но так никто не делает ни в одной мне известной In-memory СУБД. Почему? Ответ кроется в п.3.
3. Если данные хорошо разделены на горячие и холодные, то горячие лежат в In-memory СУБД, а холодные в обычной СУБД. После рестарта In-memory СУБД заливает в себя быстро горячие данные. Да, во время заливки она недоступна. Но и обычная СУБД во время холодного старта недоступна на запросы к горячим данным (которых по определению ооочень много в секунду валится), потому что она упирается в диск. При этом обычная СУБД, в которой лежат лишь холодные данные, спокойно рестартует и начинает сразу отлично работать без всякого прогрева.
4. Дампы на диск в случае In-memory СУБД дешевы. Они используют диск линейно. Диск легко шедулится в этом случвае между логом транзакций и дампом. При этом чтению эти дампы не мешают. А на запись даже половина пропускной способности обычного магнитного диска (50Mb/s) более чем достаточна для любого обозримого потока транзакций, не говоря уж о пропускной способности SSD.
5. Коллега ниже привел его опыт с TimesTen. Соглашусь с ним. Ибо старт — это просто линейное чтение с диска.
1. Холодный старт для БД в RAM происходит гораздо быстрее чем для обычной СУБД, потому что БД в RAM все данные читает, необходимые для горячей работы читает последовательно с диска (логи и снэпшоты), а обычная СУБД этого не делает, она просто стартует сразу и далее прогревается пользовательскими запросами, которые бьют в случайные части файлов на диске. По нашему опыту прогрев, скажем, Tarantool идет со скоростью 60-100Mb/s, прогрев MySQL — 2Mb/s. Соответственно, 64Gb памяти будут залиты в случае Tarantool 6-10 минут, а в случае MySQL за 9 часов. Это адок для продакшн-системы.
2. Надо отдать должное обычным СУБД — они работают сразу после старта, без прогрева. In-memory СУБД пока не загрузят вся в память целиком, не работают. Это, кстати, не сложно пофиксить. Достаточно снэпшот хранить в виде B/B+ дерева,. В этом случае на старте зачитывается только кусок лога после последнего снжпшота и далее запросы на данные, которые не загружены еще в память отдаются с диска с примерно такой же скоростью, с которой они отдаются в случае не прогретой дисковой СУБД. Но так никто не делает ни в одной мне известной In-memory СУБД. Почему? Ответ кроется в п.3.
3. Если данные хорошо разделены на горячие и холодные, то горячие лежат в In-memory СУБД, а холодные в обычной СУБД. После рестарта In-memory СУБД заливает в себя быстро горячие данные. Да, во время заливки она недоступна. Но и обычная СУБД во время холодного старта недоступна на запросы к горячим данным (которых по определению ооочень много в секунду валится), потому что она упирается в диск. При этом обычная СУБД, в которой лежат лишь холодные данные, спокойно рестартует и начинает сразу отлично работать без всякого прогрева.
4. Дампы на диск в случае In-memory СУБД дешевы. Они используют диск линейно. Диск легко шедулится в этом случвае между логом транзакций и дампом. При этом чтению эти дампы не мешают. А на запись даже половина пропускной способности обычного магнитного диска (50Mb/s) более чем достаточна для любого обозримого потока транзакций, не говоря уж о пропускной способности SSD.
5. Коллега ниже привел его опыт с TimesTen. Соглашусь с ним. Ибо старт — это просто линейное чтение с диска.
Холодный старт для «БД в RAM» будет намного ужаснее, чем для обычной СУБД.
Для этого существуют сервера-реплики.
По моему опыту (да-да, мы криволапые админы, работающие на самом высоконагруженном сервисе в России и все такое) все наоборот.
Старт БД в RAM
1. Переключаем IP с мастера на реплику
2. Делаем мастер репликой
3. Новый мастер моментально обслуживает запросы
4. Предыдущий мастер в течении часа спокойно стартует
Старт БД НЕ В RAM
1. Прогреваем скриптиками кэш, плящем с бубном, молимся, что он хотя бы за сутки прогреется и начнет с нормальной скоростью сервить запросы
2. На реплику переключать бестолку. Почему? Потому что туда не идут запросы на чтение, поэтому кв кэше там нет тех данных, которые запрашиваются часто с клиентов, и поэтому реплика будет такой же холодной как и мастер.
Старт БД в RAM
1. Переключаем IP с мастера на реплику
2. Делаем мастер репликой
3. Новый мастер моментально обслуживает запросы
4. Предыдущий мастер в течении часа спокойно стартует
Старт БД НЕ В RAM
1. Прогреваем скриптиками кэш, плящем с бубном, молимся, что он хотя бы за сутки прогреется и начнет с нормальной скоростью сервить запросы
2. На реплику переключать бестолку. Почему? Потому что туда не идут запросы на чтение, поэтому кв кэше там нет тех данных, которые запрашиваются часто с клиентов, и поэтому реплика будет такой же холодной как и мастер.
и? как закэшированность страниц ускоряет их запись?
Нормально ускоряет. Данные меняются в памяти (и пишутся в REDO), а потом не спеша выгружаются рандомным доступом на диск. Это пока кэша хватает, конечно. В остальном согласен почти полностью.
Я ведь чего вспылил? Показалось, что статья следует следующему плану:
- Рассказать всю удобную правду полностью (про скорость REDO), про неудобную (объём RAM) промолчать
- Как доходит до конкурентов (которые и не конкуренты вовсе, а просто про другие задачи), начать аккуратно передёргивать на тему «забудем про кэш» и «при любом изменении меняется всё B-дерево [целиком] [прямо на диске!]»
- Тут юные неокрепшие умы начинают воображать себе всяческие ужасы про традиционные СУБД — PROFIT!
Но если я не прав, то конечно извиняюсь. Я и сам IMDB очень даже люблю и уважаю. TimesTen тот же и MySQL Cluster.
«Нормально ускоряет. Данные меняются в памяти (и пишутся в REDO), а потом не спеша выгружаются рандомным доступом на диск. Это пока кэша хватает, конечно. В остальном согласен почти полностью» — а толку-то? Если запись бьет рандомно, то кэшируй-не-кэшируй, все равно кэш надо сбросить на диск не одим бандлом, а кусочками, каждой транзакцией в отдельное место диска, заставляя его двигать головкой (если это HDD).
1. Я не сказал дополнительно, что база данных, у которой все данные лежат в памяти, ограничена объемом памяти. Согласен с вами. Скрыл горькую правду. Причем так скрыл, что без вашего зоркого ока-то не раскопали :-) Спасибо!
2а. "«забудем про кэш»" — забудем как про страшный сон, я бы сказал.
2б. "«при любом изменении меняется всё B-дерево [целиком] [прямо на диске!]»" — не нашел у себя эту цитату. Можете дать скриншот?
3. Поделитесь, какик ужасы эти самые умы вообразили? К сожалению, не могу влезть им в голову.
Ну вы, по своему правы. Особенно в пункте один :-)
1. Я не сказал дополнительно, что база данных, у которой все данные лежат в памяти, ограничена объемом памяти. Согласен с вами. Скрыл горькую правду. Причем так скрыл, что без вашего зоркого ока-то не раскопали :-) Спасибо!
2а. "«забудем про кэш»" — забудем как про страшный сон, я бы сказал.
2б. "«при любом изменении меняется всё B-дерево [целиком] [прямо на диске!]»" — не нашел у себя эту цитату. Можете дать скриншот?
3. Поделитесь, какик ужасы эти самые умы вообразили? К сожалению, не могу влезть им в голову.
Ну вы, по своему правы. Особенно в пункте один :-)
2. О, нашел: «Недостатком этого дерева является необходимость изменять его при каждом меняющем данные запросе» — изменять его — имеется в виду изменять какой-то из его элементов. Перестраивать все дерево, разумеется не надо. Ну а если мы бы в каком-то бреду решили перестроить все дерево, то следующего предложения не было бы «что может привести к падению производительности из-за произвольного доступа к диску», потому что при перестраивании всего дерева произвольного доступа нет, ибо этот процесс можно организовать последовательно. Но смысле в этом процессе я лично не вижу. Как раз смысл B-дерева в том, чтобы менять его элементы без изменнеия всей структуры.
Разве кэш на запись у вас отложенный? По нормальному (для надежности) его нельзя отложить даже на 1 мс, а это значит запись мелкими блоками 100 IOPS (на HDD).
Я так понимаю, что коллега имеет в виду кэш для table space (write back buffer). Т.е. в журнал транзакций пишем сразу, а в table space применяем отложено. Откладывать можно с точки зрения надежности насколько угодно долго — все равно все изменнеия сохраняются в логе и при рестарте считываются и накатываются в table space.
А как «СУБД в оперативной памяти» выполняет запросы, требующие создания больших временных таблиц? Особенно, когда этих запросов много и на все сразу оперативки не хватит?
Разобью ваш вопрос на два:
1. Если цель создания временной таблицы — последовательная обработка данных, которые лежат в других таблицах не последовательно (СУБД так может делать иногда), то тогда для СУБД в оперативной памяти не нужны временные таблицы — она может обращаться к оригинальным таблицам рандомно, ибо память на рандомно работает даже быстрее чем диск последовательно.
2. Если цель создания временных таблиц — это что-то боле сложное, например, сортировка или просто промежуточные данные, которые созданы по некоему алгоритму из данных в СУБД, и они больше чем размер оперативной памяти, то… тогда, очевидно, никак. Для этих целей надо делать медленную реплику дисковой СУБД к быстрой in-memory СУБД и там спокойно и неспеша ворочать терабайтами.
1. Если цель создания временной таблицы — последовательная обработка данных, которые лежат в других таблицах не последовательно (СУБД так может делать иногда), то тогда для СУБД в оперативной памяти не нужны временные таблицы — она может обращаться к оригинальным таблицам рандомно, ибо память на рандомно работает даже быстрее чем диск последовательно.
2. Если цель создания временных таблиц — это что-то боле сложное, например, сортировка или просто промежуточные данные, которые созданы по некоему алгоритму из данных в СУБД, и они больше чем размер оперативной памяти, то… тогда, очевидно, никак. Для этих целей надо делать медленную реплику дисковой СУБД к быстрой in-memory СУБД и там спокойно и неспеша ворочать терабайтами.
2 пункт немного мифический — если промежуточные данные настолько больше исходных, надо всерьёз думать об алгоритмах. По 1-му пункту согласен на 100%.
Временные таблицы в in-memory СУБД — суть индексы, содержащие ссылки на данные. А по поводу «памяти не хватит» — опять же, повторяющиеся значения заменяются ссылками на словарь (как при сжатии обычных файлов).
Для этих целей надо делать медленную реплику дисковой СУБД к быстрой in-memory СУБД и там спокойно и неспеша ворочать терабайтами.А если неспеша нельзя?
Реальный пример — у меня на сайте есть специфическая страница, на которой есть специфический SQL-запрос, при выполнении которого MySQL создает временный файл размер в 2 ГБ (в рамках примера считаем, что изменить это никак нельзя). Если туда зайдут одновременно 5 посетителей, то потребуется 10 ГБ дискового места. Запаса оперативки такого размера, разумеется, нет. А что в таком случае сделает «СУБД в оперативной памяти»? По идее, ей ничего не мешает иметь аналогичный механизм скидывания временных таблиц на диск. Но вот имеет ли в реальности — не знаю.
Собственно, я не прошу ответа прямо сейчас. Скорее, реквестирую статью на эту тему, если возможно. :)
СУБД в оперативной памяти создаст таблицу указателей на соответствующие вхождения в словаре значений. Если это не какие-то новые значения (допустим, «склеить» две строки — это дорого) а уже существующие (99% всех запросов) — такая операция довольно экономна по памяти.
Для этих целей надо делать медленную реплику дисковой СУБД к быстрой in-memory СУБД и там спокойно и неспеша ворочать терабайтами.
А если неспеша нельзя?
По идее, ей ничего не мешает иметь аналогичный механизм скидывания временных таблиц на диск. Но вот имеет ли в реальности — не знаю.
Если не спеша нельзя, то значит репликация в СУБД, где будут ворочаться эти 10Гб не устраивает? Если так, то чем скидывание на диск поможет? :-)
Плюс, давайте рассмотрим ваш кейс. Очень вероятно, что все будет именно так как рассказал коллега в параллельном ответе.
Статья конечно, отличная, как и другие из этой серии, danikin спасибо что делитесь этой интересной информацией! Правда не понятно почему статья не оформлена как перевод? https://medium.com/@denisanikin/what-an-in-memory-database-is-and-how-it-persists-data-efficiently-f43868cff4c1#.2af61ukjs Так же поделюсь ссылками на другие статьи по теме: https://medium.com/@denisanikin
Не за что! Вам спасибо за высокую оценку! :-)
Эта статья и есть перевод. А как надо было оформить?
Эта статья и есть перевод. А как надо было оформить?
>cat /dev/zero >some_file
>И посмотрите, как быстро увеличивается размер some_file.
Мда, грустно и смешно такое читать.
Если человек ничего не знает про файловый кеш, то какие можно ожидать знания по работе реальных БД?
>И посмотрите, как быстро увеличивается размер some_file.
Мда, грустно и смешно такое читать.
Если человек ничего не знает про файловый кеш, то какие можно ожидать знания по работе реальных БД?
Утверждается, что команда выше, если ее оставить на достаточно долгое время, будет демонстрировать максимальную скорость работы диска.
Конечно, если вам не важна сохранность изменений после перезагрузки компьютера, т.е. ваша операционная система настроена так, что вся доступная оперативная память используется для write back буферов, то придется подождать какое-то время, пока все эти буфера не наполнятся.
Хотя, в большинстве случаев, даже при таком аггресивном кэшировании записи, ждать придется недолго. Слава богу, память конечная и слава богу наполнится она быстро, потому что работает быстро (перегонка из буфера в памяти приложения в буфера Linux'а большими кусками через системный вызов происходит на моем опыте со скоростью полгига в секунду и выше). После чего пойдет уже реальная запись на диск, которая будет упираться в диск. И диск при такой нагрузке будет работать на максимальной скорости, ибо писать будет строго последовательно и большими кусками. Собственно, эту максимальную скорость вы и увидите по скорости роста файла.
Но хорошо, что есть такие профессионалы как вы, которые грустят, смеются, обличают других, ничего не знающих про файловый кэш, удивляются их знаниям по работе реальных БД и знают как минимум чуть больше чем ничего про файловый кэш. Они-то нам всем сейчас расскажут как все происходит на самом деле.
Конечно, если вам не важна сохранность изменений после перезагрузки компьютера, т.е. ваша операционная система настроена так, что вся доступная оперативная память используется для write back буферов, то придется подождать какое-то время, пока все эти буфера не наполнятся.
Хотя, в большинстве случаев, даже при таком аггресивном кэшировании записи, ждать придется недолго. Слава богу, память конечная и слава богу наполнится она быстро, потому что работает быстро (перегонка из буфера в памяти приложения в буфера Linux'а большими кусками через системный вызов происходит на моем опыте со скоростью полгига в секунду и выше). После чего пойдет уже реальная запись на диск, которая будет упираться в диск. И диск при такой нагрузке будет работать на максимальной скорости, ибо писать будет строго последовательно и большими кусками. Собственно, эту максимальную скорость вы и увидите по скорости роста файла.
Но хорошо, что есть такие профессионалы как вы, которые грустят, смеются, обличают других, ничего не знающих про файловый кэш, удивляются их знаниям по работе реальных БД и знают как минимум чуть больше чем ничего про файловый кэш. Они-то нам всем сейчас расскажут как все происходит на самом деле.
Конечно расскажут ;) Сколько всего понаписано, а грамотно-то было всего-то немного поизучать, как правильно измерять производительность последовательной записи на диск и поменять команду cat на dd с правильными опциями. И работа такой команды будет гораздо ближе к тому, как работает запись в redo — синхронно, с ожиданием окончания каждой записи.
Ладно, пойдем дальше по статье…
>Во-вторых, дисковые СУБД должны сохранять данные таким образом, чтобы измененные данные можно было немедленно считать, в отличие от СУБД в оперативной памяти, которые не считывают с диска, за исключением случаев, когда при старте запускается восстановление. Именно поэтому для быстрого считывания дисковым СУБД нужны особые структуры данных, чтобы избежать полного сканирования журнала транзакций.
Можно какую-то ссылку на первоисточник такого утверждения? О какой хотя бы особо экзотичной БД идет речь? Речь об undo? Так оно точно также в памяти может хранится очень-очень долго. А если undo нет, то как же тогда ACID и как можно сравнивать нормальную RDBMS с чем-то таки типа ускоряющего кеша, который вообще не RDBMS ни разу.
>Одна из таких структур — B/B+-дерево, ускоряющее считывание данных.
По-простому, речь идет об индексах? Но какая разница, если у нас все в памяти, последовательное обращение или случайное?
Из комментариев:
>Потому что все что ушло в лог транзакций, но не записалось в дерево хранится в памяти. Рано или поздно эту память надо сбросить на диск в дерево. Механизма компактификации лога транзакций у дисковых СУБД нет (см. P.S. в моей статье про компактификацию лога транзакций), поэтому, чтобы восстановление не заняло вечности надо данные таки записать в дерево на диске, не дожидаясь даже пока кончится оперативная память.
Ух… это из какой-то параллельной вселенной знания? :)
Почитайте хоть какие-то основы что-ли https://habrahabr.ru/post/132107
>По нашему опыту прогрев, скажем, Tarantool идет со скоростью 60-100Mb/s, прогрев MySQL — 2Mb/s. Соответственно, 64Gb памяти будут залиты в случае Tarantool 6-10 минут, а в случае MySQL за 9 часов. Это адок для продакшн-системы.
А написать скриптик, который сразу после старта системы пробежится полным чтением и закинет в кэш данные по таблицам-индексам квалификация не позволяет? :)
>и? как закэшированность страниц ускоряет их запись?
даю подсказку — один блок может меняться миллионы-миллиарды раз, а записать его надо будет только 1 раз :)
— В целом статью можно было бы озаглавить «я не знаю как работают RDBMS, но in-mememory DB — это круто»
:)
По существу, мне, как человеку не знающему in-memory (и немного разбирающегося в обычных БД) гораздо интереснее было бы почитать, чем еще, кроме ограниченности размера БД, жертвуют in-memory ради производительности, т.е какие дополнительные ограничения накладывают на разработчика и архитектуру системы.
Да, и говорить про использование HDD, а не SSD для небольших баз при приличной нагрузке — это как-то странно тоже.
Ладно, пойдем дальше по статье…
>Во-вторых, дисковые СУБД должны сохранять данные таким образом, чтобы измененные данные можно было немедленно считать, в отличие от СУБД в оперативной памяти, которые не считывают с диска, за исключением случаев, когда при старте запускается восстановление. Именно поэтому для быстрого считывания дисковым СУБД нужны особые структуры данных, чтобы избежать полного сканирования журнала транзакций.
Можно какую-то ссылку на первоисточник такого утверждения? О какой хотя бы особо экзотичной БД идет речь? Речь об undo? Так оно точно также в памяти может хранится очень-очень долго. А если undo нет, то как же тогда ACID и как можно сравнивать нормальную RDBMS с чем-то таки типа ускоряющего кеша, который вообще не RDBMS ни разу.
>Одна из таких структур — B/B+-дерево, ускоряющее считывание данных.
По-простому, речь идет об индексах? Но какая разница, если у нас все в памяти, последовательное обращение или случайное?
Из комментариев:
>Потому что все что ушло в лог транзакций, но не записалось в дерево хранится в памяти. Рано или поздно эту память надо сбросить на диск в дерево. Механизма компактификации лога транзакций у дисковых СУБД нет (см. P.S. в моей статье про компактификацию лога транзакций), поэтому, чтобы восстановление не заняло вечности надо данные таки записать в дерево на диске, не дожидаясь даже пока кончится оперативная память.
Ух… это из какой-то параллельной вселенной знания? :)
Почитайте хоть какие-то основы что-ли https://habrahabr.ru/post/132107
>По нашему опыту прогрев, скажем, Tarantool идет со скоростью 60-100Mb/s, прогрев MySQL — 2Mb/s. Соответственно, 64Gb памяти будут залиты в случае Tarantool 6-10 минут, а в случае MySQL за 9 часов. Это адок для продакшн-системы.
А написать скриптик, который сразу после старта системы пробежится полным чтением и закинет в кэш данные по таблицам-индексам квалификация не позволяет? :)
>и? как закэшированность страниц ускоряет их запись?
даю подсказку — один блок может меняться миллионы-миллиарды раз, а записать его надо будет только 1 раз :)
— В целом статью можно было бы озаглавить «я не знаю как работают RDBMS, но in-mememory DB — это круто»
:)
По существу, мне, как человеку не знающему in-memory (и немного разбирающегося в обычных БД) гораздо интереснее было бы почитать, чем еще, кроме ограниченности размера БД, жертвуют in-memory ради производительности, т.е какие дополнительные ограничения накладывают на разработчика и архитектуру системы.
Да, и говорить про использование HDD, а не SSD для небольших баз при приличной нагрузке — это как-то странно тоже.
Комментирую ваше сверху вниз
1. Существенное отличие dd от cat в данном контексте я вижу лишь в том, что в dd можно настроить fsync. Наверное, вы это имели в виду про правильные опции. Сразу возникает вопрос, какой размер записи выбирать перед каждым fsync? Производительность будет отличаться в зависимость от оного размера. Цель была замерить производительность диска в самом-самом лучшем кейсе.
Жду ваш пример команды, которую можно выполнить из консоли *nix системы, и которая более точно покажет максимальную производительность диска на запись чем моя команда. Пока лишь слова.
2. К сожалению, не могу залезть вам в голову и понять, что вы додумали и какие выводы сделали из того, что додумали. У меня мысль была простая — все, что изменено в дисковой СУБД (в любой), должно меняться не только в redo логе, но и в самом табличном пространстве. Да, пусть не сразу, да можно эти изменения кэшировать в памяти (в случае краша они все равно из redo лога восстановятся), но рано или поздно их надо применить в табличное пространство, просто потому что операции SELECT не парсят redo лог (это было бы слишком дорого и долго), они лезут в табличное пространство + смотрят в то, что в кэше. У in-memory баз данных изменения не надо применять в табличное пространство — только запись в redo лог (он же лог транзакций, как я называю его в статье).
3. Где у вас все в памяти? В дисковой СУБД? Вы статью читали вообще или по верхам? :) Я процитирую специально для тех кто в танке:
«поэтому для быстрого считывания дисковым СУБД нужны особые структуры данных, чтобы избежать полного сканирования журнала транзакций.
Одна из таких структур — B/B+-дерево, ускоряющее считывание данных»
4. Мы, наверное, по разному понимаем слово компактификация. То, что я понимаю под этим словом в своей статье я написал в P.S. Не поленитесь почитать.
5. Напишите, пожалуйста, скриптик, который закинет в кэш таблицы индексы, которые не влезают в память. Если они у вас всегда влезают, то это не означает, что у всех также. И если они у вас всегда влезают, то, возможно, вам надо рассмотреть in-memory СУБД. По крайней мере, скриптик писать не придется.
6. В вашем кейсе с миллионами и миллардами изменений одного блока — все так. Запись будет ускоряться. Не видел, правда, в продакшн нагрузке такое. Обычно у меня миллионы и десятки миллионов пользователей и они все пользуются сервисом, и их данные размазаны так или иначе по диску. Хотя, конечно, для системы, где один пользователель постоянно изменяет свои данные миллионы раз, согласен с вами, кэш на запись работает хорошо.
7. Обязательно изменю заголовок, если услышу от вас знание о работе RDBMS, которое бы противоречило тому, что написано в статье.
8. О, наконец-то по существу! :) Зависит от СУБД. В случае Tarantool мы постарались, чтобы таких ограничений было минимально. ACID-транзакции, хранимые процедуры, репликация — все в Tarantool есть. Нет, правда, SQL пока. Он на подходе. Планируем к концу этого года альфа-версия. Главная жертва — это то, что все в памяти. Остальные жертвы, если они есть, они не являются следствием того, что база в памяти, а скорее следствием сфокусированности той или иногй команды in-memory СУБД на тех или иных фичах.
9. Про HDD. В том то весь и фокус, что для in-memory базы вам не нужны SSD. У вас вся запись/чтение последовательное. Почитайте все-таки внимательно статью прежде чем осуждать. Ну или так сразу и напишите, не читал, но осуждаю :-)
1. Существенное отличие dd от cat в данном контексте я вижу лишь в том, что в dd можно настроить fsync. Наверное, вы это имели в виду про правильные опции. Сразу возникает вопрос, какой размер записи выбирать перед каждым fsync? Производительность будет отличаться в зависимость от оного размера. Цель была замерить производительность диска в самом-самом лучшем кейсе.
Жду ваш пример команды, которую можно выполнить из консоли *nix системы, и которая более точно покажет максимальную производительность диска на запись чем моя команда. Пока лишь слова.
2. К сожалению, не могу залезть вам в голову и понять, что вы додумали и какие выводы сделали из того, что додумали. У меня мысль была простая — все, что изменено в дисковой СУБД (в любой), должно меняться не только в redo логе, но и в самом табличном пространстве. Да, пусть не сразу, да можно эти изменения кэшировать в памяти (в случае краша они все равно из redo лога восстановятся), но рано или поздно их надо применить в табличное пространство, просто потому что операции SELECT не парсят redo лог (это было бы слишком дорого и долго), они лезут в табличное пространство + смотрят в то, что в кэше. У in-memory баз данных изменения не надо применять в табличное пространство — только запись в redo лог (он же лог транзакций, как я называю его в статье).
3. Где у вас все в памяти? В дисковой СУБД? Вы статью читали вообще или по верхам? :) Я процитирую специально для тех кто в танке:
«поэтому для быстрого считывания дисковым СУБД нужны особые структуры данных, чтобы избежать полного сканирования журнала транзакций.
Одна из таких структур — B/B+-дерево, ускоряющее считывание данных»
4. Мы, наверное, по разному понимаем слово компактификация. То, что я понимаю под этим словом в своей статье я написал в P.S. Не поленитесь почитать.
5. Напишите, пожалуйста, скриптик, который закинет в кэш таблицы индексы, которые не влезают в память. Если они у вас всегда влезают, то это не означает, что у всех также. И если они у вас всегда влезают, то, возможно, вам надо рассмотреть in-memory СУБД. По крайней мере, скриптик писать не придется.
6. В вашем кейсе с миллионами и миллардами изменений одного блока — все так. Запись будет ускоряться. Не видел, правда, в продакшн нагрузке такое. Обычно у меня миллионы и десятки миллионов пользователей и они все пользуются сервисом, и их данные размазаны так или иначе по диску. Хотя, конечно, для системы, где один пользователель постоянно изменяет свои данные миллионы раз, согласен с вами, кэш на запись работает хорошо.
7. Обязательно изменю заголовок, если услышу от вас знание о работе RDBMS, которое бы противоречило тому, что написано в статье.
8. О, наконец-то по существу! :) Зависит от СУБД. В случае Tarantool мы постарались, чтобы таких ограничений было минимально. ACID-транзакции, хранимые процедуры, репликация — все в Tarantool есть. Нет, правда, SQL пока. Он на подходе. Планируем к концу этого года альфа-версия. Главная жертва — это то, что все в памяти. Остальные жертвы, если они есть, они не являются следствием того, что база в памяти, а скорее следствием сфокусированности той или иногй команды in-memory СУБД на тех или иных фичах.
9. Про HDD. В том то весь и фокус, что для in-memory базы вам не нужны SSD. У вас вся запись/чтение последовательное. Почитайте все-таки внимательно статью прежде чем осуждать. Ну или так сразу и напишите, не читал, но осуждаю :-)
НЛО прилетело и опубликовало эту надпись здесь
1. Ох, беда, совсем же не fsync.
https://romanrm.net/dd-benchmark
ключевое — oflag=dsync
2. В in-memory изменения рано или поздно также применять в слепок. Разница в том, что для in-memory надо записать все данные, а в обычных надо записать только измененные. Т.е ничего нового тут не придумали — весь вопрос в правильных настройках этой записи и требуемого времени восстановления после краша.
3. Предлагаю Вам все-таки забыть мифическую теорию, что дисковым базам нужно зачем-то лазить за чтением на диски, если объем данных влезает в кэш. И, кстати, если in-memory поддерживают транзакционную целостность, то как же они обходятся без предыдущих версий данных в памяти? И как долго эти данные хранятся в памяти и какой объем занимают? Об этом было бы интересно почитать.
4. В обычных rdbms компактификация зовется checkpoint — момент времени в прошлом, про который мы знаем, что все данные измененные ранее уже сброшены на диск и redo ранее этого момента нам уже не потребуется в случае старта после краша. Можно еще здесь, например, почитать, для обретения ясности в голове:
https://habrahabr.ru/post/164447
5. Скриптик у меня есть, но он для Oracle. И преимущество обычных БД в том, что закинуть можно только те данные, которым нужно там быть сразу для быстрой работы критичных запросов — обычно это небольшая часть общего объема. А остальное пускай на дисках остается. А InMemory таки объемы вообще не под силу.
6. В обычных БД можно настраивать частоту сброса горячих блоков. И, например, для настроек 1 минута или 10 минут — количество IOPS по записи в файлики будет отличаться на порядки.
7. Ну так уже, выяснили, что 1) rdbms совсем не обязательно лезть за данными на диск, если он в кэше. 2) количество записи в файлы совсем не равно количеству изменений этих данных в памяти 3) какое отношение B+ деревья ко всему этому — вообще непонятно.
8. Термин ACID относится в целом к субд, а не к транзакциям. И как-то, опять же, сравнивать SQL и NoSQL… Разные задачи.
9. Ну, хорошо, я считают, что держать маленькую highload БД на HDD — это извращение ;)
https://romanrm.net/dd-benchmark
ключевое — oflag=dsync
2. В in-memory изменения рано или поздно также применять в слепок. Разница в том, что для in-memory надо записать все данные, а в обычных надо записать только измененные. Т.е ничего нового тут не придумали — весь вопрос в правильных настройках этой записи и требуемого времени восстановления после краша.
3. Предлагаю Вам все-таки забыть мифическую теорию, что дисковым базам нужно зачем-то лазить за чтением на диски, если объем данных влезает в кэш. И, кстати, если in-memory поддерживают транзакционную целостность, то как же они обходятся без предыдущих версий данных в памяти? И как долго эти данные хранятся в памяти и какой объем занимают? Об этом было бы интересно почитать.
4. В обычных rdbms компактификация зовется checkpoint — момент времени в прошлом, про который мы знаем, что все данные измененные ранее уже сброшены на диск и redo ранее этого момента нам уже не потребуется в случае старта после краша. Можно еще здесь, например, почитать, для обретения ясности в голове:
https://habrahabr.ru/post/164447
5. Скриптик у меня есть, но он для Oracle. И преимущество обычных БД в том, что закинуть можно только те данные, которым нужно там быть сразу для быстрой работы критичных запросов — обычно это небольшая часть общего объема. А остальное пускай на дисках остается. А InMemory таки объемы вообще не под силу.
6. В обычных БД можно настраивать частоту сброса горячих блоков. И, например, для настроек 1 минута или 10 минут — количество IOPS по записи в файлики будет отличаться на порядки.
7. Ну так уже, выяснили, что 1) rdbms совсем не обязательно лезть за данными на диск, если он в кэше. 2) количество записи в файлы совсем не равно количеству изменений этих данных в памяти 3) какое отношение B+ деревья ко всему этому — вообще непонятно.
8. Термин ACID относится в целом к субд, а не к транзакциям. И как-то, опять же, сравнивать SQL и NoSQL… Разные задачи.
9. Ну, хорошо, я считают, что держать маленькую highload БД на HDD — это извращение ;)
1. Да, это флаг. А fsync — это системный вызов такой, который под капотом делает dd, когда вы ему флаг dsync задаете. Просил я вас трижды написать конкретную команду, так и не допросился. Можно мой cat заменить вот на такое: dd if=/dev/zero of=/root/testfile bs=1G count=1 oflag=dsync
2. Разница еще в том, что в in-memory записывается в слепок последовательно (раз в какое-то время во время снэпшоттинга), а в не in-memory записывается в слепок рандомно. У вас в не in-memory базе данных одно изменение стоит в среднем больше иопсов чем в in-memory, хотя и там и сям персистится.
3. Если не влезло в кэш, то, надо полагать, дисковая база данных при выполнении SELECT получает данные не рандомными обращениями в B+ деревья, а по воздуху из центрального зикурата на голубях.
Но, кажется, я начинаю понимать. Ваш вопрос такой — зачем ваще эти новомодные ин-мемори базы данных, когда есть дисковые базы данных, у которых можно задрать кэши и получить ту же инмемори. Да? Это тема отдельной статьи. У меня был доклад на хайлоуде про это. Я скоро опубликую. Если кратко, то in-memory в этом случае гораздо быстрее. Казалось бы и там все ин-мемори и здесь. Но когда база сразу заточена под in-memory, то она просто более эффективна, потому что какие-то вещи сразу по другому сделаны, без оглядки на то, что данные могут не влезть в память. В общем, расскажу.
Вторая половина вашего вопроса. База на базу не приходится. Кто-то хранит предыдущие версии (в памяти, разумеется). Кто-то блокирует все жестко. Про это тоже будут статьи обязательно.
4. Да, все веро.
5. Я придерживаюсь принципа — работает — не трож. Если Oracle работает хорошо, то не надо его менять на in-memory. Я не фанат священных войн между дисковыми и ин-мемори СУБД.
6. Да. Но, к сожалению, это не убирает рандомные обращения к диску, которые рано или поздно надо сделать, чтобы сохранить, скажем миллион изменений, которые прямо сейчас сидят в памяти и которым предстоит записаться в различные части диска.
7. 1) А, т.е. я этого факта не знал, пока вы не сказали? :) Цитирую сам себя тогда:
Во-первых, в отличие от СУБД в оперативной памяти, в традиционных СУБД необходимо считывать данные с диска при каждом запросе (давайте ненадолго забудем про кеширование, это тема для отдельной статьи).
7. 2) Не новость для меня
7. 3) Самое прямое. Это структура данных на диске для хранения индексов, которую используют традиционные дисковые СУБД. И эту структуру надо апдейтить. Пусть не на каждое изменение, но рано или поздно надо апдейтить, а значит рандомно читать от корня вниз, рандомно писать в листья, рандомно писать, чтобы сливать-разливать листья.
8. Вы задали вопрос (по существу). Я ответил. Если вам что-то не понятно, то уточните. Я не понимаю к чему этот пассаж.
9. Если маленькая highload БД помещается в память, то ей SSD не нужен. Перечитайте — статью — там популярно объяснено, почему не нужен :) Если она не помешается в память, то, возможно, она уже не такая маленькая.
2. Разница еще в том, что в in-memory записывается в слепок последовательно (раз в какое-то время во время снэпшоттинга), а в не in-memory записывается в слепок рандомно. У вас в не in-memory базе данных одно изменение стоит в среднем больше иопсов чем в in-memory, хотя и там и сям персистится.
3. Если не влезло в кэш, то, надо полагать, дисковая база данных при выполнении SELECT получает данные не рандомными обращениями в B+ деревья, а по воздуху из центрального зикурата на голубях.
Но, кажется, я начинаю понимать. Ваш вопрос такой — зачем ваще эти новомодные ин-мемори базы данных, когда есть дисковые базы данных, у которых можно задрать кэши и получить ту же инмемори. Да? Это тема отдельной статьи. У меня был доклад на хайлоуде про это. Я скоро опубликую. Если кратко, то in-memory в этом случае гораздо быстрее. Казалось бы и там все ин-мемори и здесь. Но когда база сразу заточена под in-memory, то она просто более эффективна, потому что какие-то вещи сразу по другому сделаны, без оглядки на то, что данные могут не влезть в память. В общем, расскажу.
Вторая половина вашего вопроса. База на базу не приходится. Кто-то хранит предыдущие версии (в памяти, разумеется). Кто-то блокирует все жестко. Про это тоже будут статьи обязательно.
4. Да, все веро.
5. Я придерживаюсь принципа — работает — не трож. Если Oracle работает хорошо, то не надо его менять на in-memory. Я не фанат священных войн между дисковыми и ин-мемори СУБД.
6. Да. Но, к сожалению, это не убирает рандомные обращения к диску, которые рано или поздно надо сделать, чтобы сохранить, скажем миллион изменений, которые прямо сейчас сидят в памяти и которым предстоит записаться в различные части диска.
7. 1) А, т.е. я этого факта не знал, пока вы не сказали? :) Цитирую сам себя тогда:
Во-первых, в отличие от СУБД в оперативной памяти, в традиционных СУБД необходимо считывать данные с диска при каждом запросе (давайте ненадолго забудем про кеширование, это тема для отдельной статьи).
7. 2) Не новость для меня
7. 3) Самое прямое. Это структура данных на диске для хранения индексов, которую используют традиционные дисковые СУБД. И эту структуру надо апдейтить. Пусть не на каждое изменение, но рано или поздно надо апдейтить, а значит рандомно читать от корня вниз, рандомно писать в листья, рандомно писать, чтобы сливать-разливать листья.
8. Вы задали вопрос (по существу). Я ответил. Если вам что-то не понятно, то уточните. Я не понимаю к чему этот пассаж.
9. Если маленькая highload БД помещается в память, то ей SSD не нужен. Перечитайте — статью — там популярно объяснено, почему не нужен :) Если она не помешается в память, то, возможно, она уже не такая маленькая.
1. ура
2. Это все же зависит объема измененных данных в отношении всего объема БД
3. Индексы точно также лежат в кеше. Oracle вообще пофиг, что там в блоках — данные, индексы или undo. Механизм работы с ними с точки зрения кэширования совершенно одинаков.
Я верю что in-memory быстрее для какого- набора операций — вопрос, чем при этом приходится жертвовать?
4. Тогда почему ранее Вы написали, что:
>Механизма компактификации лога транзакций у дисковых СУБД нет
5. Так я тоже не фанат, я просто не лезу в то, чего не знаю, но меня задевает, когда, вот, наоборот.
6. Все так, но это вопрос грамотного тюнинга системы. И, опять же, сохранить надо не миллион изменений, а только актуальную версию измененных данных. Вот, тот же undo, перетирается по кругу, например, в зависимости от выставленного retention.
7.3 Если это не NoSQL база и есть какие-то индексы, кроме первичных ключей, то никуда от этого не денешься в плане расположения данных. Но, еще раз напишу, что базам все равно, что там в блоках — индексы, данные — алгоритм работы с ними одинаков. Не надо никуда лезть на диски, если все помещается в память.
2. Это все же зависит объема измененных данных в отношении всего объема БД
3. Индексы точно также лежат в кеше. Oracle вообще пофиг, что там в блоках — данные, индексы или undo. Механизм работы с ними с точки зрения кэширования совершенно одинаков.
Я верю что in-memory быстрее для какого- набора операций — вопрос, чем при этом приходится жертвовать?
4. Тогда почему ранее Вы написали, что:
>Механизма компактификации лога транзакций у дисковых СУБД нет
5. Так я тоже не фанат, я просто не лезу в то, чего не знаю, но меня задевает, когда, вот, наоборот.
6. Все так, но это вопрос грамотного тюнинга системы. И, опять же, сохранить надо не миллион изменений, а только актуальную версию измененных данных. Вот, тот же undo, перетирается по кругу, например, в зависимости от выставленного retention.
7.3 Если это не NoSQL база и есть какие-то индексы, кроме первичных ключей, то никуда от этого не денешься в плане расположения данных. Но, еще раз напишу, что базам все равно, что там в блоках — индексы, данные — алгоритм работы с ними одинаков. Не надо никуда лезть на диски, если все помещается в память.
По 1 еще:
Надо только понимать, что реальная запись пойдет не одой операцией в 1g, а порциями, при этом не совсем понятно, какими
Т.е лучше явно написать что-то вида:
dd if=/dev/zero of=/root/testfile bs=1024k oflag=dsync
и наблюдать за ростом файла.
Надо только понимать, что реальная запись пойдет не одой операцией в 1g, а порциями, при этом не совсем понятно, какими
Т.е лучше явно написать что-то вида:
dd if=/dev/zero of=/root/testfile bs=1024k oflag=dsync
и наблюдать за ростом файла.
а в не in-memory записывается в слепок рандомно
Далеко не всегда верно. Если говорить, например, про Apache Cassandra (внутри LSM tree), то SSTable пишется и/или мержится на диск линейно.
*******************************************************************************
6. Да. Но, к сожалению, это не убирает рандомные обращения к диску, которые рано или поздно надо сделать, чтобы сохранить, скажем миллион изменений, которые прямо сейчас сидят в памяти и которым предстоит записаться в различные части диска.
**********************************************************************************
Расскажите как ЧАСТО и КАК делается снимок(на диск) в вашей терминологии и как он работает?
Вот база работает, в шустрой In-memory базе (в памяти) нашлепали изменения в блоках…
И… очень интересно послушать.
6. Да. Но, к сожалению, это не убирает рандомные обращения к диску, которые рано или поздно надо сделать, чтобы сохранить, скажем миллион изменений, которые прямо сейчас сидят в памяти и которым предстоит записаться в различные части диска.
**********************************************************************************
Расскажите как ЧАСТО и КАК делается снимок(на диск) в вашей терминологии и как он работает?
Вот база работает, в шустрой In-memory базе (в памяти) нашлепали изменения в блоках…
И… очень интересно послушать.
Мой типичный кейс с Tarantool:
1. Размер базы данных 200-300Gb (чистые данные весят при этом где-то 80-90% от этого значения)
2. Размер REDO логов за сутки — 20-50Gb
3. Снимок делается раз в сутки. 200-300Gb сливаются на диск целиком. Это происходит последовательно, не сильно нагружая диск и почти никак не замедляя скорость работы REDO лога
4. Количество чтений у такой базы — обычно порядка 100 тыс в секунду — они сервятся из памяти, не нагружая на 100% даже одно ядро процессора. Количество записей 30-50 тыс в секунду, совсем почти не грузят процессор и грузят диск на единицы процентов (в пике это несколько мегабайт в секунду последовательной записи на диск). Грузят они диск лишь только записью в REDO
5. Все это работает на одном сервере supermicro ценой порядка $2700-3000
6. Есть еще несколько реплик для надежности. Они на ровно таком же железе. К ним запросы не идут, они вступают в бой только при проблемах с мастером, когда он отказывает
Если вы можете при таких же входных данных достигнуть такой же производительности любой классической СУБД, то вы — гений.
1. Размер базы данных 200-300Gb (чистые данные весят при этом где-то 80-90% от этого значения)
2. Размер REDO логов за сутки — 20-50Gb
3. Снимок делается раз в сутки. 200-300Gb сливаются на диск целиком. Это происходит последовательно, не сильно нагружая диск и почти никак не замедляя скорость работы REDO лога
4. Количество чтений у такой базы — обычно порядка 100 тыс в секунду — они сервятся из памяти, не нагружая на 100% даже одно ядро процессора. Количество записей 30-50 тыс в секунду, совсем почти не грузят процессор и грузят диск на единицы процентов (в пике это несколько мегабайт в секунду последовательной записи на диск). Грузят они диск лишь только записью в REDO
5. Все это работает на одном сервере supermicro ценой порядка $2700-3000
6. Есть еще несколько реплик для надежности. Они на ровно таком же железе. К ним запросы не идут, они вступают в бой только при проблемах с мастером, когда он отказывает
Если вы можете при таких же входных данных достигнуть такой же производительности любой классической СУБД, то вы — гений.
Спасибо за пример, тут конечно хорошо, что запсь на диск снапшота не влияет на работу базы, т.к. чтения идут из памяти.
Гипотетически может замедлить запись в редо(т.е. commit'ы).
База конечно небольшая, но учитывая стоимость железа конечно отличный результат.
Гипотетически может замедлить запись в редо(т.е. commit'ы).
База конечно небольшая, но учитывая стоимость железа конечно отличный результат.
Гипотетически может замедлить запись в редо(т.е. commit'ы).
Не замедляет. Там версии в оперативной памяти создаются. То есть снимок не тормозит OLTP за счёт большего расхода оперативной памяти. Ну и плюс в том что пишется последовательно, в отличии от рандомной записи грязных блоков, конечно.
Все верно говорите. По сути, есть два параллельных процесса записи на диск, каждый из которых пишет строго последовательно — запись в REDO и запись снимка. Запись снимка можно вести на «всех парах», потому что запись в REDO обычно редко потребляет больше нескольких % от максимальной производительности диска.
Это он OLTP при таком подходе не тормозит, а запись в редо может.
Но конечно на таком объеме это не критично.
Запустите копирование двух пусть последовательных файлов на чистом диске одновременно.
На активных системах редо выносят на отдельные диски, чтобы не рушить эту последовательную запись, ну и они могу быть сильно нагруженными.
Т.к. ВЕСЬ DML проходит через логи.
И если у вас они не нагружены, значит больше чтений в базе.
Но конечно на таком объеме это не критично.
Запустите копирование двух пусть последовательных файлов на чистом диске одновременно.
На активных системах редо выносят на отдельные диски, чтобы не рушить эту последовательную запись, ну и они могу быть сильно нагруженными.
Т.к. ВЕСЬ DML проходит через логи.
И если у вас они не нагружены, значит больше чтений в базе.
Только лучше не копирование файлов, а копирование из /dev/zero, потому что копирование файла это чтение с диска и запись, а копирование из /dev/zero в файл — это только запись. Запускал. Один файл — 100Mb/s, два файла — по 50Mb/s. Это Linux. Там достаточно оптимально все устроено с точки зрения шаринга ресурсов диска.
Не подскажете, а 100 тысяч запросов каких? Т.е. key-value или более сложные выборки, и если да, то насколько сложные?
Более менее простые. Или выборки/обновления по первичному/вторичному индексу или Lua-код из, условно, 5-10 строчек, внутри которого один-два подобных запроса.
Если для какого-то запроса нет индекса, и база будет вынуждена сначала выбрать из одного индекса и потом выборку проверить на пересечение с другим индексом, насколько это будет медленнее? Т.е. интересно было бы услышать какие-то сравнительные примеры. Это особенно любопытно в свете озвученной цифры в 100000, ведь это фактически означает 10000 наносекунд на запрос, и это очень маленькая цифра ))
Ну, хорошо, я считают, что держать маленькую highload БД на HDD — это извращение ;)
Думаю, Mail.Ru с их нагрузками делают это вовсе не потому, что они представители ЛГБТ или у них денег нет на диски (тем более, что всего-то речь идет о каких-то 8-ми серверах).
А потому что провели замеры и убедились, что на линейном чтении/записи никакой необходимости в SSD нет, а места для множества журналов WAL на HDD все же побольше/подешевле.
А InMemory таки объемы вообще не под силу.
А RDBMS такие скорости не под силу.
И что?
Каждому инструменту — свое предназначение.
Гвозди отверткой забивать невозможно.
Появился образ эдакого «папы» по базам данных. С высоты своего огромного опыта работы может использовать фразочки типа «вам квалификация не позволяет?» или подлавливать на терминах типа «вы, наверное, индекс имели в виду?».
Под конец еще написать: «А вообще, я бы хотел почитать про другое».
При этом думать, что весь мир вокруг работает так же как у него, типа все по щелкчу пальцев побежали и поменяли HDD на SSD, или написали «скриптик, который пробежится полным чтением и закинет в кэш данные по таблицам-индексам» (это ваще огонь, я считаю). Про закешированность страниц тоже отличный коммент с подсказкой от «папы», вы правда считаете что сказали что-то умное?
Под конец еще написать: «А вообще, я бы хотел почитать про другое».
При этом думать, что весь мир вокруг работает так же как у него, типа все по щелкчу пальцев побежали и поменяли HDD на SSD, или написали «скриптик, который пробежится полным чтением и закинет в кэш данные по таблицам-индексам» (это ваще огонь, я считаю). Про закешированность страниц тоже отличный коммент с подсказкой от «папы», вы правда считаете что сказали что-то умное?
Да я не против, чтобы люди изобретали свое колесо, лучше прежних колес, особенно если за это платят.
Только хорошо бы для начала разобраться, и понимать, как работает то, что уже давно придумано.
>Про закешированность страниц тоже отличный коммент с подсказкой от «папы», вы правда считаете что сказали что-то умное?
Так кто-то же должен был это сказать, развеять, так сказать, заблуждения автора.
А какие претензии к скриптам разогрева кеша баз? Первый раз про такое слышите?
>типа все по щелкчу пальцев побежали и поменяли HDD на SSD
ну, сравните стоимость замены HDD небольшого объема на SSD и стоимость написания своей собственной RDMS, которая будет отличаться только в том, что скидывает данные на диски не случайным, а последовательным способом.
Только хорошо бы для начала разобраться, и понимать, как работает то, что уже давно придумано.
>Про закешированность страниц тоже отличный коммент с подсказкой от «папы», вы правда считаете что сказали что-то умное?
Так кто-то же должен был это сказать, развеять, так сказать, заблуждения автора.
А какие претензии к скриптам разогрева кеша баз? Первый раз про такое слышите?
>типа все по щелкчу пальцев побежали и поменяли HDD на SSD
ну, сравните стоимость замены HDD небольшого объема на SSD и стоимость написания своей собственной RDMS, которая будет отличаться только в том, что скидывает данные на диски не случайным, а последовательным способом.
Вам никто и не предлагает писать собственную СУБД. Если вы ее напишите, то единственным ее пользователем будете вы сами, поэтому вам лично дешевле остаться на SSD.
А какие претензии к скриптам разогрева кеша баз? Первый раз про такое слышите?
Зачем применять методики из одной (непохожей) СУБД, для СУБД другой?
Каждому инструменту — свой способ заточки.
В in-memory СУБД разогрев происходит автоматом при рестарте.
А чтобы не было простоев — просто используются сервера-реплики.
Один уже разогрет и работает, второй в этом момент рестартует.
А как влияет скорость репликации между серверами на «гарантированно в памяти» и какая скорость синхронизации?
А зачем там скорость в репликации-то в данном способе использования?
Рабочая разогретая реплика содержит 100% данных.
Вторая реплика может при этом стартовать весьма и весьма неспешно — этого никто и не заметит.
Рабочая разогретая реплика содержит 100% данных.
Вторая реплика может при этом стартовать весьма и весьма неспешно — этого никто и не заметит.
Вроде как очевидно.
Если сервер А упал, запросы должны на серевер Б. Сервер А обязан содержать данные, подтвержденные сервером Б (фактически двухфазный комит). Этот двухфазный комит стоит какие-то ресурсов.
В противном случае, если Сервер А подтвердил данные, а сервер Б еще не подтвердил их,
то после момента переключения Клиент будет пытаться оперировать данными, подтвержденными ТОЛЬКО сервером А о которых сервер Б еще не знает.
Если сервер А упал, запросы должны на серевер Б. Сервер А обязан содержать данные, подтвержденные сервером Б (фактически двухфазный комит). Этот двухфазный комит стоит какие-то ресурсов.
В противном случае, если Сервер А подтвердил данные, а сервер Б еще не подтвердил их,
то после момента переключения Клиент будет пытаться оперировать данными, подтвержденными ТОЛЬКО сервером А о которых сервер Б еще не знает.
Если у вас есть PITR и WAL никуда не делись, то ничто никуда не теряется.
Только вот изменения должны успеть записаться не только в локальный REDO, но и в REDO на всех репликах. То есть мы не имеем права завершать транзакцию пока реплики не отрапортуют о том, что успешно записали в REDO. То есть во время выполнения транзакции (при наличии синхронных реплик) включаются сетевые издержки на взаимодействие между репликами. Разумеется, можно делать часть реплик или даже все реплики асинхронными. Тогда сетевые издержки включаться не будут.
Согласен на 100%. Ну и потом, разгорев кэша идет вслепую, без информации, что именно надо греть. Греть-то надо данные, которые часто запрашиваются. А узнать кто запрашивается часто можно только после того как запросили. Логи предыдущих запросов (всех!) обычно не хранят и обычно разогрев на основании этих логов не делают. Но даже если уважаемый zhekap это делает, то он с высокой вероятностью получит при разогреве те же рандомные обращения к диску, что и при запросах от пользователя, потому что никто не гарантирует, что горячие данные сведены на диске в одну кучу. В IMDB как раз это гарантируется тем, что все данные в IMDB считаются горячими и все они одним линейным куском быстро зачитываются в память при старте.
*******************************************
Так кто-то же должен был это сказать, развеять, так сказать, заблуждения автора.
*****************************************************
Сверху вниз читаю,…
статья понравилась, но мне непонятно зачем автор начал сравнивать in-memory с обычными, в архитектуре которых у него ну явные пробелы.
Лучше бы больше рассказал про особенности — вот про те же снимки, которые как я понял аналог наших чекпоинтов, но каким-то чудными образом меньше нагружают I/O, избегая рэндом-записи.
Так кто-то же должен был это сказать, развеять, так сказать, заблуждения автора.
*****************************************************
Сверху вниз читаю,…
статья понравилась, но мне непонятно зачем автор начал сравнивать in-memory с обычными, в архитектуре которых у него ну явные пробелы.
Лучше бы больше рассказал про особенности — вот про те же снимки, которые как я понял аналог наших чекпоинтов, но каким-то чудными образом меньше нагружают I/O, избегая рэндом-записи.
Про особенности я рассказал в коменте ниже. Сделаю еще одну статью, чтобы рассказать детали. Насчет обычных баз. Сравнение было приведено с целью, чтобы объяснить, что in-memory работают быстрее обычных и показать каким образом они быстрее. Но, похоже, я наступил на больные мозоли тех, кто всю жизнь работает с обычными СУБД, и кто сопротивляется наступлению новых технологий.
Согласен с вами! К сожалению, таких пап много. Когда достижений показать нельзя, то остается только сидеть на хабре папствовать :-)
Часто в таких дискуссиях много полезного узнаешь, по сути очень интересно читать, а авторы своими вопросами много полезной инфы открывают. Мне нравится и вопросы читать и ответы. Не нравится только переход на «вам квалификации не хватило?» — это реально обидно и хочеться ругаться. Для профессионалов это неприемлемо.
Согласен!
Самое любопытное, что извинений за оскорбления не следует.
Самое любопытное, что извинений за оскорбления не следует.
Странно извиняться перед автором безграмотной статьи, которому ни разу не стыдно.
И я не услышал, что именно, кроме отсутствия квалификации помешало грамотно построить работу с кешэм в MySQL? За что извиняться то?
И я не услышал, что именно, кроме отсутствия квалификации помешало грамотно построить работу с кешэм в MySQL? За что извиняться то?
Странно извиняться перед автором безграмотной статьи, которому ни разу не стыдно.
И я не услышал, что именно, кроме отсутствия квалификации помешало грамотно построить работу с кешэм в MySQL? За что извиняться то?
Использовать MySQL в данных случаях дороже на 1 миллионо долларов.
Вот здесь про это детально написано:
Как сэкономить миллион долларов с помощью Tarantool
Учитывая все коментарии выше, где безграмотность? Цитату в студию.
Далее, в какую сумму вы, уважаемый, квалифицированный знаток MySQL, оцениваете свои услуги по грамнотной настройке индексов MySQL, чтобы он работал быстрее Тарантула или хотя бы также? Назовите свою цену, я вас найму, срубите легкие деньги.
Скажу более, Percona вас оторвет с руками за любые деньги. Они с вашей помощью ускорят миллионы инстансов MySQL по всему миру до скорости in-memory баз данных и заработают на это миллиарды долларов.
И, наконец, Фейсбук тут же возьмем вас на работу — они выкинут все их кэши и прочие самописные штуки типа Tao или Dragon поверх MySQL и останутся с голым оптимизированным MySQL, работающим быстрее чем in-memory базы данных. Их специалисты, работающие в крупнейших технологических компаниях мира ждут вас с распростертыми объятиями. Странно6 что вы еще там не работаете.
Далее, в какую сумму вы, уважаемый, квалифицированный знаток MySQL, оцениваете свои услуги по грамнотной настройке индексов MySQL, чтобы он работал быстрее Тарантула или хотя бы также? Назовите свою цену, я вас найму, срубите легкие деньги.
Скажу более, Percona вас оторвет с руками за любые деньги. Они с вашей помощью ускорят миллионы инстансов MySQL по всему миру до скорости in-memory баз данных и заработают на это миллиарды долларов.
И, наконец, Фейсбук тут же возьмем вас на работу — они выкинут все их кэши и прочие самописные штуки типа Tao или Dragon поверх MySQL и останутся с голым оптимизированным MySQL, работающим быстрее чем in-memory базы данных. Их специалисты, работающие в крупнейших технологических компаниях мира ждут вас с распростертыми объятиями. Странно6 что вы еще там не работаете.
Спасибо, конечно, но я несколько другой области тружусь, где NoSQL до сих пор не особо применимы, а используются классические RDBMS.
Речь идет о финансовых данных, биллинг мобильных операторов, карточные процессинг и т.п.
Для FaceBook потерять пару комментов или отобразить их чуть позже — это фигня.
Для всего, что связано напрямую с деньгами такие вещи недопустимы.
Вот и вся разница.
Мне кажется, Вам отлично удаются маркетинговые статьи типа вот этой:
http://www.cnews.ru/news/top/2016-12-05_subd_mailru_tarantool_cherez_tri_nedeli_prevratitsya
И они вполне впечатлят каких-нибудь топ-менеджеров и принесут Вам доходы.
Но тут, по-большей части, технические специалисты и такого рода вещи, конечно, могут вызывать раздражение, так как админы и программисты в большинстве не очень любят маркетологов :)
Речь идет о финансовых данных, биллинг мобильных операторов, карточные процессинг и т.п.
Для FaceBook потерять пару комментов или отобразить их чуть позже — это фигня.
Для всего, что связано напрямую с деньгами такие вещи недопустимы.
Вот и вся разница.
Мне кажется, Вам отлично удаются маркетинговые статьи типа вот этой:
http://www.cnews.ru/news/top/2016-12-05_subd_mailru_tarantool_cherez_tri_nedeli_prevratitsya
И они вполне впечатлят каких-нибудь топ-менеджеров и принесут Вам доходы.
Но тут, по-большей части, технические специалисты и такого рода вещи, конечно, могут вызывать раздражение, так как админы и программисты в большинстве не очень любят маркетологов :)
1. «где NoSQL до сих пор не особо применимы, а используются классические RDBMS» — так примените RDBMS в той области, где безграмотные и криволапые админы, не умеющие написать скриптик прогрева применяют NoSQL. Не уходите от ответа!
2. Опять господин соврамши. Это статья не моя. Это журналисты из cnews. Они понабрались случайных фактов, вырванных из контекста, и сделали статью. Ее финальный вид с нами не согласовали. Оракл мы не собираемся убить через 3 недели альфа-версией SQL — это бред.
3. Хорошо, если это раздражение подкреплено какими-то фактами, а не слепой нелюбовью. Я тоже вас не люблю, вы неприятный человек, скажу прямо, но тем не менее спокойно с вами общаюсь, задаю вопросы по существу, до оскорблений не опускаюсь. И все, чтобы докопаться до истины, которая где-то сильно глубоко засела в вашей голове и не выходит наружу :-)
2. Опять господин соврамши. Это статья не моя. Это журналисты из cnews. Они понабрались случайных фактов, вырванных из контекста, и сделали статью. Ее финальный вид с нами не согласовали. Оракл мы не собираемся убить через 3 недели альфа-версией SQL — это бред.
3. Хорошо, если это раздражение подкреплено какими-то фактами, а не слепой нелюбовью. Я тоже вас не люблю, вы неприятный человек, скажу прямо, но тем не менее спокойно с вами общаюсь, задаю вопросы по существу, до оскорблений не опускаюсь. И все, чтобы докопаться до истины, которая где-то сильно глубоко засела в вашей голове и не выходит наружу :-)
1. Так я такого не предлагал. Это Вы считаете, что можно поставить две разные технологии в заведомо неравные условия и на основе этого делать какие-то выводы :) Я-то понимаю, что RDBMS — да, очень хреновенько масштабируется. Вот отсюда и надо расписывать преимущества NoSQL, не забывая и минусы. А не с точки зрения работы с дисками или тем, что LMS всегда лучше B-деревьев.
2. Фух, ура, у меня еще пока есть шанс не остаться безработным.
3. Т.е слова «папик, у которого нет достижений» не стоит расценивать, как наивную попытку менять задеть? :)
2. Фух, ура, у меня еще пока есть шанс не остаться безработным.
3. Т.е слова «папик, у которого нет достижений» не стоит расценивать, как наивную попытку менять задеть? :)
1. В какие неравные условия я поставил и какие выводы я сдалал. Цитату дадите?
2. Я бы не зарекался на вашем месте.
3. Вы даже цитировать не умеете. Я такого не говорил. Я говорил это: «Согласен с вами! К сожалению, таких пап много. Когда достижений показать нельзя, то остается только сидеть на хабре папствовать :-)»
2. Я бы не зарекался на вашем месте.
3. Вы даже цитировать не умеете. Я такого не говорил. Я говорил это: «Согласен с вами! К сожалению, таких пап много. Когда достижений показать нельзя, то остается только сидеть на хабре папствовать :-)»
Спасибо, конечно, но я несколько другой области тружусь, где NoSQL до сих пор не особо применимы, а используются классические RDBMS.
Речь идет о финансовых данных, биллинг мобильных операторов, карточные процессинг и т.п.
Неужели все сырые данные сразу пишутся в РСУБД непосредственно?
А не используется никаких промежуточных специализированных более быстрых не РСУБД?
Я не очень понял термин «сырые данные».
По сути в силу необходимости ACID — да, когда вы расплатились в картой в магазине, то oracle выполнил 3-4 commit в redo.
По сути в силу необходимости ACID — да, когда вы расплатились в картой в магазине, то oracle выполнил 3-4 commit в redo.
Биллинг, например.
Он же изначально в форме не очень удобной для RDBMS.
К примеру, при звонке при тарификации по времени — разве не имеет разве смысла временно сохранить время начала звонка в другой более специализированной СУБД, чтобы записать в RDBMS просто весь звонок целиком как одну запись. Когда разговор закончится и будет известно и время начала и время конца.
Я имею ввиду нечто подобное под сырыми данными.
Он же изначально в форме не очень удобной для RDBMS.
К примеру, при звонке при тарификации по времени — разве не имеет разве смысла временно сохранить время начала звонка в другой более специализированной СУБД, чтобы записать в RDBMS просто весь звонок целиком как одну запись. Когда разговор закончится и будет известно и время начала и время конца.
Я имею ввиду нечто подобное под сырыми данными.
Ну почему?
Просто пишутся маркеры: начало звонка, конце звонка. двумя записями.
Потом проходит обработка ETL и приведение в более удобоваримую аналитическую форму/кубики.
Просто пишутся маркеры: начало звонка, конце звонка. двумя записями.
Потом проходит обработка ETL и приведение в более удобоваримую аналитическую форму/кубики.
С биллингом попроще в силу того, что если даже база недоступна, то коммутационное оборудование все равно генерит записи и они рано или поздно все равно доедут до базы. Небольшой уход в минус для абонентов вполне допустим.
В момент набора номера в базу вообще ничего не пишется, приложение по номеру примерно оценивает тариф (по закешированной в приложении информации об абоненте и тарифах) и выдает прикидку на коммутатор об оценочной максимальной продолжительности вызова. По окончании разговора, да — идет вставка записи в БД, и, чуть позже, обновление баланса.
Вот, платежи, должны быть закоммичены в момент, когда осуществляются. Но для этого можно использовать отдельную небольшую БД, а затем уже с небольшой задержкой обновлять баланс в биллинге — как это обычно и происходит.
В момент набора номера в базу вообще ничего не пишется, приложение по номеру примерно оценивает тариф (по закешированной в приложении информации об абоненте и тарифах) и выдает прикидку на коммутатор об оценочной максимальной продолжительности вызова. По окончании разговора, да — идет вставка записи в БД, и, чуть позже, обновление баланса.
Вот, платежи, должны быть закоммичены в момент, когда осуществляются. Но для этого можно использовать отдельную небольшую БД, а затем уже с небольшой задержкой обновлять баланс в биллинге — как это обычно и происходит.
А если undo нет, то как же тогда ACID и как можно сравнивать нормальную RDBMS с чем-то таки типа ускоряющего кеша, который вообще не RDBMS ни разу.
Tarantool является однопоточным. С последовательной обработкой запросов.
Авторы утверждают, что отсутствие необходимости блокировок позволило серьезно поднять производительность.
Настолько серьезно, что Tarantool никогда не упирался на их задачах в процессор — раньше упирался в сеть.
Следовательно многоядерность и не нужна. Хотя, обсуждался вопрос реализовать многоядерность хотя бы для операций чтения.
Ну а если вам нужно задействовать все ядра сервера — запускаете несколько экземпляров Tarantool`а, между которыми шардите данные.
В такой же однопоточной системе последовательного исполнения запросов в пределах одного экземпляра Tarantool весь ACID зависит только от того, что вы там в хранимых процедурах намудрите. Даже напротив, напрограммировать в хранимых процедурах что, что нарушающее ACID довольно непросто.
1) про закешированность повторю Дениса — кейз с многократным обновлением одного блока означает что у вас странная нагрузка, что то типа ведения пяти счетчиков для миллионов событий. В этом случае вам вообще реляционные базы противопоказаны — для этих целей гораздо проще и дешевле использовать IMDB
2) слыхал. Даже видал как эти скрипты часами «прогревались», и наблюдал как они сосут в память данные одной таблицы, а юзера долбятся в другую. Но, наверное, я мало знаю о хороших скриптах прогревания баз.
3) Ну сравнил. Для тысячи серверов получил денег на зарплату для команды разработчиков, так что это не довод. Плюс чисто по личному опыту, хотя я, конечно, не мастак по части баз данных — с реляционной mysql и на SSD гиморы бывают, а тарантул на говнотазу со старыми HDD пашет как ракета.
Я бы с удовольствием во всех случаях работал бы с ораклом или sql сервером, люблю их за качество. Но поднимать эти самолёты ради микросервиса, который на тарантуле поднимается за 15 минут вместе с кодовой базой и держит при этом нагрузку в разы большую, уж простите
2) слыхал. Даже видал как эти скрипты часами «прогревались», и наблюдал как они сосут в память данные одной таблицы, а юзера долбятся в другую. Но, наверное, я мало знаю о хороших скриптах прогревания баз.
3) Ну сравнил. Для тысячи серверов получил денег на зарплату для команды разработчиков, так что это не довод. Плюс чисто по личному опыту, хотя я, конечно, не мастак по части баз данных — с реляционной mysql и на SSD гиморы бывают, а тарантул на говнотазу со старыми HDD пашет как ракета.
Я бы с удовольствием во всех случаях работал бы с ораклом или sql сервером, люблю их за качество. Но поднимать эти самолёты ради микросервиса, который на тарантуле поднимается за 15 минут вместе с кодовой базой и держит при этом нагрузку в разы большую, уж простите
1) есть существенная разница между блоком и записью. В одном блоке записей-то может быть немало
2) при правильном подходе работает
я согласен с 3 и дальше, но тут надо четко понимать круг решаемых задач и связанные с этим ограничения.
Т.е не пытаться сравнивать несравнимое и находить минусы там, где их нет при правильном подходе.
Можно и на grep и awr базы писать, но этот как-то не совсем же базы.
2) при правильном подходе работает
я согласен с 3 и дальше, но тут надо четко понимать круг решаемых задач и связанные с этим ограничения.
Т.е не пытаться сравнивать несравнимое и находить минусы там, где их нет при правильном подходе.
Можно и на grep и awr базы писать, но этот как-то не совсем же базы.
Я, в общем-то «старовер» в базах данных и руками пока не трогал «базы в памяти».
Насчет всех БД не скажу, но тот же SQL Server поддерживает несколько сценариев восстановления, в том числе и «последняя запись в лог». Так же не БД занимается сжатием лога, а отдельные сервисы. Так же управляет тем, в какую страницу БД и что писать.
Задача дерева — ускорять поиск. к считыванию имеет отношение организация хранения страниц в БД.
Это не недостаток дерева, а любого индекса. Но для этого есть оптимизирующие механизмы.
Не могли бы прояснить несколько не понятных для меня нюансов.
1. Для каких сценариев применения предподчительны такие БД, или на каких сценариях вы приводите сравнения? Похоже идет разговор и различных сценариях применения.
2. Предположим, у нас есть две БД: disk & InMemory. Обе содержат одинаковый объем данных, одинаковые структуры (таблицы/индексы и т.д.), одинаковые сценарии работы и нагрузка. работают в одинаковом окружении, и памяти у обоих +25% к размеру данных, включая индексы. В чем по вашему ожидаются отличия в поведении этих двух БД?
Насчет всех БД не скажу, но тот же SQL Server поддерживает несколько сценариев восстановления, в том числе и «последняя запись в лог». Так же не БД занимается сжатием лога, а отдельные сервисы. Так же управляет тем, в какую страницу БД и что писать.
Одна из таких структур — B/B+-дерево, ускоряющее считывание данных.
Задача дерева — ускорять поиск. к считыванию имеет отношение организация хранения страниц в БД.
Недостатком этого дерева является необходимость изменять его при каждом меняющем данные запросе, что может привести к падению производительности из-за произвольного доступа к диску.
Это не недостаток дерева, а любого индекса. Но для этого есть оптимизирующие механизмы.
Не могли бы прояснить несколько не понятных для меня нюансов.
1. Для каких сценариев применения предподчительны такие БД, или на каких сценариях вы приводите сравнения? Похоже идет разговор и различных сценариях применения.
2. Предположим, у нас есть две БД: disk & InMemory. Обе содержат одинаковый объем данных, одинаковые структуры (таблицы/индексы и т.д.), одинаковые сценарии работы и нагрузка. работают в одинаковом окружении, и памяти у обоих +25% к размеру данных, включая индексы. В чем по вашему ожидаются отличия в поведении этих двух БД?
IMDB применяются для минимизации времени отклика.
Есть предел, которому RDBMS не переступить (какой бы высокой не была пропускная способность).
Есть предел, которому RDBMS не переступить (какой бы высокой не была пропускная способность).
А можно как-то в цифрах/попугаях выразить сравнительно? (можно эмпирически)
Например: Обращения к постоянной памяти — стоит Х попугаев, обращение к оперативной памяти — Y, перестройка индекса — ..., запуск и первые 100500 запросов с перебором случайных не повторяющихся значений —
Хотелось бы понять «за чей счет банкет» в IMDB? неужели «бесплатно» и нету никаких минусов-ограчений?
Как по мне, так в вырожденных случаях, я не вижу серьезных отличий.
Если зная характер нагрузки на мое приложение, я просто воткну какой-то Dictionary (Key-Value) массив в памяти с «капелькой мозгов» в бизнес логику — я получу результат по отклику не хуже (на 1000...10000 запросов).
Пока я вижу пояснение в виде: если ОС или БД закеширует в памяти ответы на запросы это будет хуже, чем наша IMDB которая их загрузит сразу.
Если наша IMDB будет писать лог это будет хуже, чем запись лога DiskDB и т.д.
Например: Обращения к постоянной памяти — стоит Х попугаев, обращение к оперативной памяти — Y, перестройка индекса — ..., запуск и первые 100500 запросов с перебором случайных не повторяющихся значений —
Хотелось бы понять «за чей счет банкет» в IMDB? неужели «бесплатно» и нету никаких минусов-ограчений?
Как по мне, так в вырожденных случаях, я не вижу серьезных отличий.
Если зная характер нагрузки на мое приложение, я просто воткну какой-то Dictionary (Key-Value) массив в памяти с «капелькой мозгов» в бизнес логику — я получу результат по отклику не хуже (на 1000...10000 запросов).
Пока я вижу пояснение в виде: если ОС или БД закеширует в памяти ответы на запросы это будет хуже, чем наша IMDB которая их загрузит сразу.
Если наша IMDB будет писать лог это будет хуже, чем запись лога DiskDB и т.д.
Цифр под рукой нет (да и что бы вам дали абстрактные попугаи?), а «банкет» оплачивается из многих факторов.
Если очень надо, всё в ход идёт. Повторюсь, речь идёт о гарантированном времени обработки очень короткой и простой единичной транзакции. RDBMS можно хорошо тюнить на производительность, но по тюнингу времени отклика возможностей меньше. Особенно когда счёт идёт на микросекунды.
Минус, по большому счёту один — данные могут не поместиться в оперативку. Ну и всякая мелочь — например, что нет SQL, если мы от него отказались (кому-то критично, кому-то нет).
откуда это?
- Из того что данные гарантированно находятся в ОП (в RDBMS этого гарантировать нельзя)
- Из того что исключается или минимизируется сетевое взаимодействие (если IMDB на том же хосте что и Application)
- Из того что полностью исключается SQL (парсинг и оптимизация)
- Из того что ослабляется или исключается журналирование (в большинстве RDBMS этого сделать нельзя)
- Из того что нет издержек по сбросу грязных данных на диск и не надо ждать завершения контрольных точек
- ...
Если очень надо, всё в ход идёт. Повторюсь, речь идёт о гарантированном времени обработки очень короткой и простой единичной транзакции. RDBMS можно хорошо тюнить на производительность, но по тюнингу времени отклика возможностей меньше. Особенно когда счёт идёт на микросекунды.
Минус, по большому счёту один — данные могут не поместиться в оперативку. Ну и всякая мелочь — например, что нет SQL, если мы от него отказались (кому-то критично, кому-то нет).
Если наша IMDB будет писать лог это будет хуже, чем запись лога DiskDB и т.д.
откуда это?
откуда это?
Пардон. Описка.
Это из вышележащих коментариев сторонников IMDB у меня сложилось мнение, что каким-то магическим образом работа с диском IMDB куда эффективнее DiskDB на сопоставимых операциях.
«Из того что полностью исключается SQL (парсинг и оптимизация)» — планы исполнения и предкомпиляция обычно отрабатывает один раз, а дальше от оптимизатора зависит. ну… тут допустим бонус у IMDB.
По прочим пунктам:
«Из того что данные гарантированно находятся в ОП (в RDBMS этого гарантировать нельзя)» — на 1000 одинаковых запросов точно будет. на 1...10 точно пофиг. пинг дольше будет идти :)
«Из того что исключается или минимизируется сетевое взаимодействие (если IMDB на том же хосте что» — межпроцессное общение не убирается в любом случае, а копирование через разделяемую память на одном хосте идет быстро, pipe или сокеты уже не важно. Опять же как будет сделана реализация. при одинаковом механизме разницы быть не должно.
«Из того что ослабляется или исключается журналирование (в большинстве RDBMS этого сделать нельзя)» — я приводил пример. не думаю что только МС такой «хитро-мудрый», а все остальные не догадались. при одинаковом механизме разницы быть не должно.
«Из того что нет издержек по сбросу грязных данных на диск и не надо ждать завершения контрольных точек» — тут точно будет паритет. Если вы пишете на диск свой журнал, то ОС будет управлять сбросом, или вы будете ее пинать, что бы сбросила данные или нет. Как напишет программер.
Из вашего пояснения я понял что IMDB это жутко оптимизированный кеш в памяти, поверх файловых кешей ОС, к которому прикрутили свой оптимизированный на одну задачу интерфейс.
Цена: Убрали уверсальность решаемых задач и ограничили объем обрабатываемых данных.
точно пофиг. пинг дольше будет идти
Если всё на одном хосте, никакого пинга вообще не будет. Кроме того, похоже вы не понимаете. Нам требуется гарантированное время, а при наличии кэша ничего гарантировать нельзя. Можно говорить только о производительности, в плане среднего количества транзакций за единицу времени, но никак не о времени обработки отдельной транзакции.
планы исполнения и предкомпиляция обычно отрабатывает один раз, а дальше от оптимизатора зависит
То есть, самый первый запрос будет выполняться дольше, а нам надо гарантированное время. И не надо говорить про «прогрев». Разобранный план запросто может уйти из Library Cache (терминология Oracle) и мы получим медленный запрос в произвольный момент времени. Можно конечно пытаться добиться того чтобы план не вытеснялся, но это та ещё магия.
межпроцессное общение не убирается в любом случае
Я об этом и говорю: IPC быстрее TCP через Loopback, который быстрее чем TCP через сеть. А TCP через сеть это очень весомые (и не всегда гарантированные) миллисекунды.
Как-то вот так всё выглядит
при одинаковом механизме разницы быть не должно
За MS не скажу, но, например, в Oracle можно делать async commit, зато в TimesTen, помимо этого, журнал, при желании, можно вообще отключить. Разную специфику типа работы с temporary сегментами здесь не рассматриваем, поскольку очень специфично. Разница есть, поверьте.
Если вы пишете на диск свой журнал, то ОС будет управлять сбросом, или вы будете ее пинать, что бы сбросила данные или нет.
Грязные данные это не журнал, а те изменения которые уже зафиксированы в журнале, но не сброшены на диск (рандомным доступом). В IMDB нет грязных данных, по определению, поскольку все данные в ОП.
Цена: Убрали уверсальность решаемых задач и ограничили объем обрабатываемых данных
Да. И это всегда так. Специализированные решения всегда эффективнее универсальных. На своих задачах, разумеется.
Это из вышележащих коментариев сторонников IMDB у меня сложилось мнение, что каким-то магическим образом работа с диском IMDB куда эффективнее DiskDB на сопоставимых операциях
Вот именно этого заблуждения я и опасался. Автор не пишет об этом. То что он написал про журналирование один в один соответствует журналированию, например, в Oracle.
Если требуется «гарантированный отклик» — тогда понятно. только спец решение.
Вопрос как этот отклик гарантируется, если «на одном хосте сидели ...»? жесткая привязка к ядрам процессора? к каналам ввода-вывода на «железо»?
Подозреваю, что под «прогрев» подразуевается помещение в оперативную память данных вообще до того, как БД станет доступна для других. Тут или залить snapshot IMDB или скриптами погонять — результат один.
Судя по коментариям, это могут быть или данные в журнале IMDB, еще не сброшенные на диск, или shapshot еще не сброшенный на диск. Эта операция тоже «не дешевая».
Тот же Windows 8...16 гб сливает в hybernate файл оперативную память пару десятков секунд в фактически монопольном доступе к жесткому диску.
Вопрос как этот отклик гарантируется, если «на одном хосте сидели ...»? жесткая привязка к ядрам процессора? к каналам ввода-вывода на «железо»?
Подозреваю, что под «прогрев» подразуевается помещение в оперативную память данных вообще до того, как БД станет доступна для других. Тут или залить snapshot IMDB или скриптами погонять — результат один.
Грязные данные это не журнал, а те изменения которые уже зафиксированы в журнале, но не сброшены на диск (рандомным доступом). В IMDB нет грязных данных, по определению, поскольку все данные в ОП.
Судя по коментариям, это могут быть или данные в журнале IMDB, еще не сброшенные на диск, или shapshot еще не сброшенный на диск. Эта операция тоже «не дешевая».
Тот же Windows 8...16 гб сливает в hybernate файл оперативную память пару десятков секунд в фактически монопольном доступе к жесткому диску.
Если требуется «гарантированный отклик»
Часто, но не только. Например Oracle Exalytics использует TimesTen для того чтобы поворочать аналитику в памяти (SQL у TimesTen, кстати, вполне полноценный). Летает как самолёт (стоит тоже).
жесткая привязка к ядрам процессора
Бывает.
Тут или залить snapshot IMDB или скриптами погонять — результат один.
Как я уже писал выше, снапшот заливается достаточно быстро. Это более дешёвая операция чем выполнение скриптов.
Судя по коментариям, это могут быть или данные в журнале
Не судите по комментариям. Грязные данные — в сегменте данных. То что не зафиксировано в журнале называется проще — незакомиченные транзакции. Ну и опять интересно, судя по каким комментариям? Я таких не помню.
Эта операция тоже «не дешевая».
Достаточно дешёвая.
Эта операция в большинстве моих кейсов — дешевая. Будет отдельная статья с деталями.
Минус, по большому счёту один — данные могут не поместиться в оперативку
Разные инструменты — разный способ работы с ними.
Не нужно пытаться работать с in-memory ровно так же как и с RDBMS.
Наоборот — тоже не нужно.
Примеры использования очень разных СУБД в одном проекте для очень разных подзадач. Тут вам и in-memory и документарно-ориентированные и Cassandra-подобные с MapReduce…
https://habrahabr.ru/company/targetix/blog/266009/
https://habrahabr.ru/company/dca/blog/260845/
Способы обойти ограничения по памяти, если уж так прям край как надо именно in-memory СУБД, имеются.
Можно разделить данные по разным серверам — шардинг.
Можно использовать в Tarantool движок vinyl (в прежних версия sphia), а не движок memx, который включен в Tarantool по умолчанию — данные не обязаны помещаться в оперативную память. Правда vinyl/sphia это append only.
Сейчас Mail.ru проводит эксперименты по использованию vinyl в Tarantool для поиска по письмам. Речь идет о пентабайтах данных. Понятно, что это уже не чистая in-memory СУБД получается, но, возможно, для кого-то и такой способ использования окажется полезным.
Ускорять чтение данных — имеется в виду делать быстрее селекты. В это словосочетание входят и поиск по индексу и чтение данных. Простите, что я термин считывание понимаю не так как вы его понимаете. Хотя, это в практике вещей тут — взять слово, выдрать из контекста, понять его по другому и дальше научить аффтора прописным истинам, сделав вывод из своей фантазии, приписав автору того, чего нет на самом деле. Смысл? Поднять свою значимость?
«Это не недостаток дерева, а любого индекса» — ну а вы контекст расширьте. Фраза написана в контексте, что это дерево на диске. Каждое изменение (да и чтение тоже, кстати) — произвольный доступ к диску. В IMDB такого нет — там все в памяти. Недостаток это или нет? Вопрос филосовский. Кому-то нравится, когда помедленнее.
1,2. Я понял уже, что это тема для отельной статьи, даже двух. Так вот быстро и подробно не ответишь. Скоро опубликую. Вызову, наверное, опять шквал гнева у любителей старины, но что поделаешь :-)
«Это не недостаток дерева, а любого индекса» — ну а вы контекст расширьте. Фраза написана в контексте, что это дерево на диске. Каждое изменение (да и чтение тоже, кстати) — произвольный доступ к диску. В IMDB такого нет — там все в памяти. Недостаток это или нет? Вопрос филосовский. Кому-то нравится, когда помедленнее.
1,2. Я понял уже, что это тема для отельной статьи, даже двух. Так вот быстро и подробно не ответишь. Скоро опубликую. Вызову, наверное, опять шквал гнева у любителей старины, но что поделаешь :-)
НЛО прилетело и опубликовало эту надпись здесь
Хороший инструмент, но есть кейс, когда он не сработает.
Если размер таблиц(ы) больше объема ОЗУ выделенного для in-memory СУБД на сервере.
Тут все равно нужно будет обращаться к диску чтобы нужные данные подкачать в память.
Если размер таблиц(ы) больше объема ОЗУ выделенного для in-memory СУБД на сервере.
Тут все равно нужно будет обращаться к диску чтобы нужные данные подкачать в память.
Автор вначале приводит SQL базы данных и противопоставляет им NoSQL (key-value хранилища).
Это как бы не совсем адекватно и не всем подходит.
Это как бы не совсем адекватно и не всем подходит.
Что конкретно не адекватно?
Простите, если открываю тут Америку для Вас, но, наверное, тем что NoSQL — это не RDBMS :)
Они совсем разные по своим возможностям и реализации.
Нереляционные СУБД правильно будет сравнивать с другими нереляционными СУБД.
Например сравнить Redis и RocksDB.
А для объектно-реляционных СУБД можно было бы сравнить обычный вариант и вариант когда вся БД расположена на виртуальном диске размещенном в оперативной памяти.
А то получается, что сравнивают «коня и трепетную лань».
Нереляционные СУБД правильно будет сравнивать с другими нереляционными СУБД.
Например сравнить Redis и RocksDB.
А для объектно-реляционных СУБД можно было бы сравнить обычный вариант и вариант когда вся БД расположена на виртуальном диске размещенном в оперативной памяти.
А то получается, что сравнивают «коня и трепетную лань».
«Нереляционные СУБД правильно будет сравнивать с другими нереляционными СУБД.» — я не понимаю, по какому принципу в вашей голове сортируется правильно/не правильно, поэтому сразу вопрос — нельзя ли в той же логике сказать, что СУБД правильно сравнивать с другими СУБД, а не с движками? RocksDB — это движок, т.е. бибиотека, которую вы вкомпиливаете себе в код, в нем нет клиент-серверной модели, нет репликации, все это надо делать ручками.
«когда вся БД расположена на виртуальном диске размещенном в оперативной памяти» — мне трудно представить кейс, когда бы я стал такое делать. Компьютер перезагрузился и данные пропали. Поэтому я пока не вижу повода писать статью. Напишите вы, я почитаю.
Но раз уж вы настаиваете, то Redis и RocksDB были созданы для разных видов нагрузок. Redis — это ин-мемори кэш с персистенсом и репликацией. Он используется для высоких нагрузок на чтение-запись и обеспечивает скорость ответа в милисекунды. RocksDB — это дисковый движок, построенный на LSM дереве. Используется там, где надо хранить данные, не влезающие в память (в отличие от Redis) и на которые большая нагрузка на запись. RocksDB сильно медленнее Redis на чтение, медленнее и на запись, но уже не так драмматично (цифры под рукой есть, но не пишу их сюда, дабы не развивать отдельный холи вор, ибо цифры цифрам рознь, получены при разных условиях и тд). Чем Redis лучше RocksDB? Он быстрее, у него есть репликация из коробки, он работает как клиент-сервер. Чем RocksDB лучше Redis? Он менее требователен к оперативной памяти чем Redis на одном и том же объеме данных.
«когда вся БД расположена на виртуальном диске размещенном в оперативной памяти» — мне трудно представить кейс, когда бы я стал такое делать. Компьютер перезагрузился и данные пропали. Поэтому я пока не вижу повода писать статью. Напишите вы, я почитаю.
Но раз уж вы настаиваете, то Redis и RocksDB были созданы для разных видов нагрузок. Redis — это ин-мемори кэш с персистенсом и репликацией. Он используется для высоких нагрузок на чтение-запись и обеспечивает скорость ответа в милисекунды. RocksDB — это дисковый движок, построенный на LSM дереве. Используется там, где надо хранить данные, не влезающие в память (в отличие от Redis) и на которые большая нагрузка на запись. RocksDB сильно медленнее Redis на чтение, медленнее и на запись, но уже не так драмматично (цифры под рукой есть, но не пишу их сюда, дабы не развивать отдельный холи вор, ибо цифры цифрам рознь, получены при разных условиях и тд). Чем Redis лучше RocksDB? Он быстрее, у него есть репликация из коробки, он работает как клиент-сервер. Чем RocksDB лучше Redis? Он менее требователен к оперативной памяти чем Redis на одном и том же объеме данных.
Для Postgres можно в памяти хранить индексы, что в некоторых случаях ускоряет процесс.
НЛО прилетело и опубликовало эту надпись здесь
Ускоряет, но лишь частично. После обращения по индексу, нужно вытащить с диска с данные. А это обычно рандомное обращение к диску.
Ну, справедливости ради, существуют планы выполнения запросов, на которых достаточно обращаться только к индексам.
т.е по факту, как только латентность постоянной памяти, будет сопоставима с оперативной памятью, ваше решение перестанет быть «крутым».
если делать не на hdd а на ssd с pcie/NVMe то недостатки в виде «рандомное обращение к диску» перестануть быть весомым фактором.
судя по упоминаемому выше серверу супермикро.
Может у вас есть какие-то сравнительные тесты?
если делать не на hdd а на ssd с pcie/NVMe то недостатки в виде «рандомное обращение к диску» перестануть быть весомым фактором.
судя по упоминаемому выше серверу супермикро.
Может у вас есть какие-то сравнительные тесты?
Ну если вам от этого спать спокойней, то, да перестанет )))
А когда, сверх того, постоянная память будет адресоваться напрямую процессором и при этом каждое изменение (каждый байт) будет моментально и синхронно персистить с латентностью текущей RAM, то и ваши любимые дисковые СУБД полетят в помойку — достаточно будет взять любую библиотеку структур данных, например, плюсовую STL и использовать ее как персистентную базу данных.
Насчет SSD — там такая же проблема как с HDD, но не в тех масштабах. На 2 порядка быстрее HDD, но все еще на 4 порядка медленнее памяти.
Есть сравнительные тесты Tarantool с другими СУБД в памяти: http://highscalability.com/blog/2015/12/30/how-to-choose-an-in-memory-nosql-solution-performance-measur.html, https://medium.com/@rvncerr/tarantool-vs-competitors-racing-in-microsoft-azure-ebde9c5d619#.ispbmmius. С дисковыми СУБД сравнений нет — там и так понятно, что выигрышь на несколько порядков.
А когда, сверх того, постоянная память будет адресоваться напрямую процессором и при этом каждое изменение (каждый байт) будет моментально и синхронно персистить с латентностью текущей RAM, то и ваши любимые дисковые СУБД полетят в помойку — достаточно будет взять любую библиотеку структур данных, например, плюсовую STL и использовать ее как персистентную базу данных.
Насчет SSD — там такая же проблема как с HDD, но не в тех масштабах. На 2 порядка быстрее HDD, но все еще на 4 порядка медленнее памяти.
Есть сравнительные тесты Tarantool с другими СУБД в памяти: http://highscalability.com/blog/2015/12/30/how-to-choose-an-in-memory-nosql-solution-performance-measur.html, https://medium.com/@rvncerr/tarantool-vs-competitors-racing-in-microsoft-azure-ebde9c5d619#.ispbmmius. С дисковыми СУБД сравнений нет — там и так понятно, что выигрышь на несколько порядков.
Насчет SSD — там такая же проблема как с HDD, но не в тех масштабах. На 2 порядка быстрее HDD, но все еще на 4 порядка медленнее памяти.
Как то вы слишком фривольно манипулируете цифрами.
Если протестировать RAM disk, для i7-5820K @ 4GHz, G.Skill 2133 DDR4
Sequential Read: 7407.388 MB/s
Sequential Write: 11478.855 MB/s
Random Read 512KB: 7218.039 MB/s
Random Write 512KB: 11622.896 MB/s
Для Samsung 950 Pro 512 Gb
Sequential Read: 2599 MB/s
Sequential Write: 1530 MB/s
Random Read 512KB: 1216 MB/s
Random Write 512KB: 1513 MB/s
Разницу на один порядок между оперативной памятью и SSD видно.
по IOPS разница: ~554 373 IOPS против ~44 9000 по чтению примерно в 10 раз
и
~468 428 IOPS против ~13 516 по записи примерно в 30 раз.
Можно, конечно заморочиться с ECC и размером кеша для серверов, но еще в 10 раз мы не натянем ну никак.
При интенсивной записи, станет колом что IMDB что DiskDB на записи журанала. Но это граничные условия, можем их опустить.
А вы утверждаете о разнице на 4 порядка (10 тыс раз!!!) между RAM и SSD!
Как то не аккуратно :)
Я говорю об SSD дисках.
https://en.wikipedia.org/wiki/Solid-state_drive: Время случайного доступа 0.1ms (1e-4)
https://en.wikipedia.org/wiki/Dynamic_random-access_memory: Время случайного доступа 50ns (5e-9)
Разница даже 5 порядков.
Вы говорите от NVM https://en.wikipedia.org/wiki/NVM_Express. Они подороже чем SSD диски, но побыстрее. Там проблемы случайного доступа почти нет.
Правда, странно вы меряете случайный доступ — 512КБ блоками. Если мерять 4К блоками, то результат будет в несколько раз скромнее у конкретно Samsung 950 Pro: http://www.anandtech.com/show/9702/samsung-950-pro-ssd-review-256gb-512gb/7
Ну и давайте вспомним тот факт, что RDBMS медленнее IMDB, даже если все сидит в кэшах (т.е. тут уже не важно какой диск под базой, пусть это даже супербыстрый флеш).
В качестве иллюстрации могу привести пример теста MariaDB — одной из самых прогрессивных с точки зрения производительности RDBMS на текущий момент (это заоптимизированный форк MySQL, ее авторы — создатели MySQL, ушли оттуда и организовали свою компанию после того как Oracle купил MySQL), по крайней мере среди open source. Этот тест провели сами создатели этой СУБД, т.е. мы можем надеяться, что СУБД настроена на максимальную пиковую производительности. Вот подробности про тест: https://mariadb.org/10-1-mio-qps/. Он показывает миллион запросов в секунду на дорогущей машине IBM Power8 с 20 ядрами и 160 хардварными потоками (читай, на самом деле, как с 160 ядрами). А вот тест IMDB Tarantool, который показывает миллион запросов в секунду на одноядерном виртуальном амазоновском сервере за $5 в месяц: https://gist.github.com/danikin/a5ddc6fe0cedc6257853 (кстати, исходник открыт — можете повтоить своими руками, причем бесплатно — ибо этот сервер попадает под free tier у Амазона).
Отличие, грубо говоря, в 160 раз. Можно тут долго спорить о реальной параллельности ядер у Power8 (хотя 20 честных ядер там точно есть), а также о том, на каком железе работают сервисs Амазона, но, в целом, отличие очевидно. Заметьте, это достаточно честный бенч в том смысле, что в обоих случаях вендо выжал максимум из своего детища, максимально хорошо его настроив.
https://en.wikipedia.org/wiki/Solid-state_drive: Время случайного доступа 0.1ms (1e-4)
https://en.wikipedia.org/wiki/Dynamic_random-access_memory: Время случайного доступа 50ns (5e-9)
Разница даже 5 порядков.
Вы говорите от NVM https://en.wikipedia.org/wiki/NVM_Express. Они подороже чем SSD диски, но побыстрее. Там проблемы случайного доступа почти нет.
Правда, странно вы меряете случайный доступ — 512КБ блоками. Если мерять 4К блоками, то результат будет в несколько раз скромнее у конкретно Samsung 950 Pro: http://www.anandtech.com/show/9702/samsung-950-pro-ssd-review-256gb-512gb/7
Ну и давайте вспомним тот факт, что RDBMS медленнее IMDB, даже если все сидит в кэшах (т.е. тут уже не важно какой диск под базой, пусть это даже супербыстрый флеш).
В качестве иллюстрации могу привести пример теста MariaDB — одной из самых прогрессивных с точки зрения производительности RDBMS на текущий момент (это заоптимизированный форк MySQL, ее авторы — создатели MySQL, ушли оттуда и организовали свою компанию после того как Oracle купил MySQL), по крайней мере среди open source. Этот тест провели сами создатели этой СУБД, т.е. мы можем надеяться, что СУБД настроена на максимальную пиковую производительности. Вот подробности про тест: https://mariadb.org/10-1-mio-qps/. Он показывает миллион запросов в секунду на дорогущей машине IBM Power8 с 20 ядрами и 160 хардварными потоками (читай, на самом деле, как с 160 ядрами). А вот тест IMDB Tarantool, который показывает миллион запросов в секунду на одноядерном виртуальном амазоновском сервере за $5 в месяц: https://gist.github.com/danikin/a5ddc6fe0cedc6257853 (кстати, исходник открыт — можете повтоить своими руками, причем бесплатно — ибо этот сервер попадает под free tier у Амазона).
Отличие, грубо говоря, в 160 раз. Можно тут долго спорить о реальной параллельности ядер у Power8 (хотя 20 честных ядер там точно есть), а также о том, на каком железе работают сервисs Амазона, но, в целом, отличие очевидно. Заметьте, это достаточно честный бенч в том смысле, что в обоих случаях вендо выжал максимум из своего детища, максимально хорошо его настроив.
Давайте смотреть сопоставимые вещи, а не абстрактные «случайный доступ».
C учетом того, что у статьях упоминается своя версия fork и работы со страницами памяти, мы же оперируем большими наборами данных а не один… двумя байтами, соответсветнно и все «платежи», в виде промахов в кеш процессора, переупорядочиваяния станиц памяти при освобождении и будем пытаться включать. Так чуть корректнее будет.
Одинаковый тест, сопоставимые условия — сопоставимый итоговый результат. IOPS и передача данных.
По итогу и получатся, что при всех узкоспециализиованных преимуществах сумма всех факторов приводит к такому результату.
С этой точки зрения, сравнения количество полезной «работы» в итоге будет более корретно?
C учетом того, что у статьях упоминается своя версия fork и работы со страницами памяти, мы же оперируем большими наборами данных а не один… двумя байтами, соответсветнно и все «платежи», в виде промахов в кеш процессора, переупорядочиваяния станиц памяти при освобождении и будем пытаться включать. Так чуть корректнее будет.
Одинаковый тест, сопоставимые условия — сопоставимый итоговый результат. IOPS и передача данных.
По итогу и получатся, что при всех узкоспециализиованных преимуществах сумма всех факторов приводит к такому результату.
С этой точки зрения, сравнения количество полезной «работы» в итоге будет более корретно?
Спасибо за ссылки. Интересно.
Повторюсь, что я не спец по IMDB и возможно не корретно понял ваш тест.
Но я не заметил у вас:
не понял на чем основано, если тестовые сценарии то разные.
Повторюсь, что я не спец по IMDB и возможно не корретно понял ваш тест.
Но я не заметил у вас:
How sysbench OLTP operates
During each iteration, a worker thread chooses a random table from the pool of defined OLTP tables. For the point selects it randomly chooses a row number between 1 and the number of rows per table (--oltp-table-size). The range queries, the update, and the delete / insert operations also use random row IDs.
Отличие, грубо говоря, в 160 раз
не понял на чем основано, если тестовые сценарии то разные.
В одинаковых условиях мы сравнивали in-memory СУБД, например, вот тут http://highscalability.com/blog/2015/12/30/how-to-choose-an-in-memory-nosql-solution-performance-measur.html
Там многие популярные IMDB участвуют. Наш Tarantool самый быстрый. Ну и что скажете вы? Тест же провели вы сами, значит верить ему нельзя. Троль всегда найдет как затроллить.
Добавить к тем же условиям MySQL? Ну можно. Он будет минимум в 10 раз медленнее по моеиу опыту (даже если все-все-все будет сидеть в памяти, без единой операции к диску). Но мой опыт же для вас не авторитет и мое умение настраивать RDBMS для вас тоже не акторитет. Поэтому ссылаюсь на признанных профессионалов в этой области (MariaDB). Да, условия теста у нас и у них разные. Т.е. они в целом похожи — рандомно селектим и апдейдим в таблицу, но не вот тебя прям одно и тоже.
Далее еще нюанс. Делать бенчи, чтобы для вас лично показать, что IMDB сильно быстрее чем RDBMS на сходной нагрузки и далее долго и нудно убеждать вам, что условия разные и настроили мы RDBMS на максимальную производительность. Зачем? Чтобы что? Чтобы вы перешли на IMDB. Вы перейдете сами, если поймете, что ваше решение не справляется и вы никак не можете его ускорить. Однако, если на вашей нагрузке лошадь выгоднее автомобиля, то предлагаю ничего не менять, никуда не смотреть и быть довольным лошадью, пока она не перестанет справляться :-)
Там многие популярные IMDB участвуют. Наш Tarantool самый быстрый. Ну и что скажете вы? Тест же провели вы сами, значит верить ему нельзя. Троль всегда найдет как затроллить.
Добавить к тем же условиям MySQL? Ну можно. Он будет минимум в 10 раз медленнее по моеиу опыту (даже если все-все-все будет сидеть в памяти, без единой операции к диску). Но мой опыт же для вас не авторитет и мое умение настраивать RDBMS для вас тоже не акторитет. Поэтому ссылаюсь на признанных профессионалов в этой области (MariaDB). Да, условия теста у нас и у них разные. Т.е. они в целом похожи — рандомно селектим и апдейдим в таблицу, но не вот тебя прям одно и тоже.
Далее еще нюанс. Делать бенчи, чтобы для вас лично показать, что IMDB сильно быстрее чем RDBMS на сходной нагрузки и далее долго и нудно убеждать вам, что условия разные и настроили мы RDBMS на максимальную производительность. Зачем? Чтобы что? Чтобы вы перешли на IMDB. Вы перейдете сами, если поймете, что ваше решение не справляется и вы никак не можете его ускорить. Однако, если на вашей нагрузке лошадь выгоднее автомобиля, то предлагаю ничего не менять, никуда не смотреть и быть довольным лошадью, пока она не перестанет справляться :-)
Не понял вашу глубокую мысль. Просите. Можете проще и популярнее сформулировать?
НЛО прилетело и опубликовало эту надпись здесь
Или допустим недостатки Lua
Язык выбран за максимальную скорость, имхо.
Недостатки-недостатками, но решение на JavaScript, Python, Java, Ruby или кто другой внутри — было бы медленее существенно.
Вот именно. Когда-нибудь мы про это напишем, покажем бенчи. Вызовем, разумеется, гнев любителей похапэ :-)
но решение на JavaScript, Python, Java, Ruby или кто другой внутри — было бы медленее существенно
Откуда такая уверенность про Java? У него JIT, который пилят уже как минимум десяток лет, очень неплох.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что такое СУБД в оперативной памяти и как она эффективно сохраняет данные