Что такое СУБД в оперативной памяти и как она эффективно сохраняет данные

    Сальвадор Дали, Дезинтеграция постоянства памяти. 1952—1954. Холст, масло.

    Всем привет. Кто-то из вас, возможно, уже знаком с СУБД для данных в оперативной памяти, но на всякий случай — по ссылке можно найти их общее описание. Если вкратце, такие СУБД хранят данные целиком в оперативной памяти. Что это означает? Каждый раз, отправляя запрос на поиск или обновление данных, вы обращаетесь только к оперативной памяти в обход жесткого диска — на нем никакие операции не производятся. И это хорошо, потому что оперативная память работает намного быстрее любого диска. Примером такой СУБД является Memcached.

    Секундочку, скажете вы, а как же восстановить данные после перезагрузки или поломки машины с такой СУБД? Если на машине установлена СУБД для хранения данных только в оперативной памяти, о них можно забыть: при отключении питания данные бесследно исчезнут.

    Можно ли объединить достоинства хранения данных в оперативной памяти с надежностью проверенных временем СУБД вроде MySQL или Postgres? Конечно! Повлияет ли это на производительность? Вы удивитесь, но нет!

    Встречайте СУБД для данных в оперативной памяти, обеспечивающие их сохранность: Redis, Aerospike, Tarantool.

    Вы можете спросить, как же эти СУБД обеспечивают сохранность данных? Фокус в том, что все данные по-прежнему хранятся в оперативной памяти, но каждая операция вдобавок записывается в расположенный на диске журнал транзакций. Посмотрите на изображение ниже:



    Первое, что вы, возможно, вынесете из этой схемы, — скорость исполнения запросов нисколько не страдает, несмотря на то что теперь СУБД постоянно создает записи в журнале. Производительность при этом не проседает, потому что все запросы по-прежнему обращаются напрямую к оперативной памяти. Отличные новости! :-) А как обстоят дела с обновлением данных? Каждое обновление (назовем его транзакцией) не только происходит в оперативной памяти, но и записывается на диск. На медленный диск. Такая ли это проблема? Давайте посмотрим на следующее изображение:



    Транзакции всегда записываются в самый конец журнала. В чем плюс такого подхода? Диск работает довольно быстро. Если говорить о классическом жестком диске (HDD), он может записывать данные в конец файла со скоростью до 100 Мбайт/с. Не верите? Запустите этот тест из командной строки в Unix/Linux/macOS:

    cat /dev/zero >some_file

    И посмотрите, как быстро увеличивается размер some_file. Итак, жесткий диск весьма проворен при последовательной записи, однако его скорость резко падает при произвольной записи: обычно он способен выполнить около 100 таких операций.

    При побайтовой записи, когда каждый байт записывается в произвольное место на жестком диске, вы можете увидеть, что реальная максимальная производительность диска составляет 100 байтов/с. Еще раз, всего-навсего 100 байтов/с! Разница в шесть порядков между пессимистичной (100 байтов/с) и оптимистичной (100 000 000 байтов/с) оценками скорости доступа к диску столь велика потому, что для поиска по произвольному сектору на диске требуется физическое движение головки диска, тогда как при последовательном доступе можно считывать данные по мере вращения диска; головка при этом остается неподвижной.

    Если говорить о твердотельном накопителе (SSD), здесь ситуация лучше из-за отсутствия движущихся частей. Однако соотношение пессимистичной (1—10 тысяч операций в секунду) и оптимистичной (200—300 Мбайт/с) оценок остается практически неизменным: четыре-пять порядков. Подробнее с этими показателями можно ознакомиться по ссылке.

    Таким образом, наша СУБД для данных в оперативной памяти, по сути, наводняет журнал транзакциями со скоростью до 100 Мбайт/с. Достаточно ли это быстро? Очень быстро. Предположим, размер транзакции составляет 100 байтов, тогда скорость будет равняться миллиону транзакций в секунду! Это настолько хороший показатель, что вам абсолютно точно не придется волноваться о производительности диска при использовании подобной СУБД. По ссылке ниже находится подробный тест производительности одной СУБД в оперативной памяти при обработке миллиона транзакций в секунду, где проблемным элементом является не диск, а процессор:

    https://gist.github.com/danikin/a5ddc6fe0cedc6257853.

    Подведем итог всему вышесказанному о дисках и СУБД в оперативной памяти:

    1. СУБД в оперативной памяти не обращаются к диску при обработке запросов, не изменяющих данные.
    2. СУБД в оперативной памяти все-таки обращаются к диску при обработке запросов, изменяющих данные, но работают с ним на максимальной скорости.

    Почему же традиционные дисковые СУБД не берут на вооружение описанные техники? Во-первых, в отличие от СУБД в оперативной памяти, в традиционных СУБД необходимо считывать данные с диска при каждом запросе (давайте ненадолго забудем про кеширование, это тема для отдельной статьи). Заранее неизвестно, каков следующий запрос, поэтому можно считать, что каждый раз будет требоваться произвольный доступ к диску, а это, напомню, пессимистичный сценарий.

    Во-вторых, дисковые СУБД должны сохранять данные таким образом, чтобы измененные данные можно было немедленно считать, в отличие от СУБД в оперативной памяти, которые не считывают с диска, за исключением случаев, когда при старте запускается восстановление. Именно поэтому для быстрого считывания дисковым СУБД нужны особые структуры данных, чтобы избежать полного сканирования журнала транзакций.

    Одна из таких структур — B/B+-дерево, ускоряющее считывание данных. Недостатком этого дерева является необходимость изменять его при каждом меняющем данные запросе, что может привести к падению производительности из-за произвольного доступа к диску. Довольно много движков СУБД основано на B/B+-деревьях, из популярных можно назвать InnoDB от MySQL и движок Postgres.

    Существует другая структура, которая лучше справляется с записью данных, — LSM-дерево. Это относительно новый тип деревьев, который не решает проблему произвольного считывания, но помогает избавиться от части проблем, связанных с произвольной записью. Примерами движков, использующих такие деревья, могут служить RocksDB, LevelDB или Vinyl. На изображении ниже приведена сводная информация о типах СУБД и используемых ими деревьях:



    Резюмируем вышесказанное: СУБД в оперативной памяти, обеспечивающие сохранность данных, как при считывании, так и при записи могут работать очень быстро, а точнее — так же быстро, как и СУБД в оперативной памяти, которые не сохраняют данные на диске: первые используют диск настолько эффективно, что он никогда не становится проблемным местом.

    P. S.

    Последняя — по порядку, но не по значимости — тема, которую я хотел бы затронуть в статье, посвящена снимкам состояния. Снятие таких снимков необходимо для компактификации журналов транзакций. Снимок состояния базы данных — это копия всех имеющихся данных. Снимка и журналов с последними транзакциями достаточно для восстановления состояния вашей базы данных. Поэтому, имея свежий снимок состояния, можно удалять все старые журналы транзакций, предшествующие дате снимка.

    Зачем компактифицировать журналы? Потому что чем больше журналов, тем дольше будет восстановление базы данных. И потом, вам ведь не хочется захламлять диск устаревшей и бесполезной информацией (ну хорошо, старые журналы иногда здорово выручают, но давайте поговорим об этом в отдельной статье).

    По сути, периодически делая снимки состояния, вы целиком копируете базу данных из оперативной памяти на диск. Как только копирование закончилось, можно смело удалять все журналы, в которых нет транзакций, записанных позже последней транзакции в вашем снимке состояния. Довольно просто, не так ли? А все потому, что все транзакции начиная с самого первого дня попадают в снимок.

    Вы могли задаться вопросом: как сохранить консистентное состояние базы данных на диск и как определить последнюю зафиксированную в снимке транзакцию при условии постоянного поступления новых транзакций? Об этом мы поговорим в следующей статье.
    Mail.ru Group
    1,168.82
    Building the Internet
    Share post

    Similar posts

    Comments 242

      –1
      Что делать когда место на диске кончится?
        +2
        1. Купить диск побольше?
        2. Купить ещё дисков?
        3. Удалить устаревшие данные?
          +3
          4. Купить еще побольше дисков побольше
          … и лучше заранее
            –1
            3. Удалить устаревшие данные?
            В системах хранения, основанных на журналировании, удаление данных ведёт не к освобождению места, а к дополнительным записям на диск, т.е. к уменьшению свободного места (если оставить в стороне создание снимков состояния, которое само по себе требует довольно больших объёмов свободного места).
              0

              а compress/vacuum по расписанию или запросу чем не подходит?

            –1
            sudo rm -rf /*
            
              +1
              патч Бармина…
              0
              Полагаю периодически делается снимок состояния базы в памяти на диск, и лог транзакций чистится.
                0
                Место в памяти, нет?
                +1
                Если кто-то действительно заинтересован разобраться в вопросе рекомендую:



                В общем автор статьи делает упор на то, что БД в памяти просто быстрее работают, потому что пишут только в память, а она быстрее.

                Так же делает упор, что в disk oriented DB, в плохом случае, при каждом чтении мы будет лезть на диск. Что подразумевает, что он сравнивает in-memory DB запущенную на PC при достаточным объемом памяти с disk oriented DB, у которой нет достаточно памяти, чтобы держать необходимые страницы в buffer pool.
                  +1

                  Спасибо за ссылку на лекцию от CMU. В свою очередь могу порекомендовать материал аффилированный с SAP, но его стоит воспринимать только в качестве"концепта" в рамках БД в памяти — https://hpi.de/plattner/research/in-memory-data-management-for-enterprise-systems.html.

                    0
                    И ещё один отличный курс, уже от open.hpi, на ту же тему. Ведёт «сам» дядько Платтнер (один из основателей SAP-а). Все видео и слайды доступны «безвоздмездно и без СМС», т.е. даром. Рассказывается и про историю идеи, и про концепт, и про внутреннее устройство.
                    In-Memory Data Management 2015
                    https://open.hpi.de/courses/imdb2015
                    0
                    Отчасти. В вопросе чтения — согласен с вами. И тут про сравнение с дисковой СУБД с buffer pool будет отдельная статья. В вопросе записи — не согласен. Запись в дисковой СУБД идет в B/B+ дерево как ни крути. И это медленней чем запись последовательно в файл.
                      +1
                      Я не совсем понимаю о чем мы тут говорим.

                      Насколько я понимаю in-memory db vs disk oriented dbs. Дисковые БД в большинстве случаев будут медленнее, чем in-memory. Даже в случае чтения, потому что нет overhead на buffer pool, по другому организованы locking & latching, а так же используется другая схема организации данных в памяти, другой concurrency control. Это как раз и дает хороший прирост производительности, даже для чтения.

                      Есть огромное количество in-memory Db, которые даже и не задумываются о durability, то есть совсем не пишут на диск.

                      В всех мне известных нормальных disk oriented БД так же происходит запись сначала в transaction log, что подразумевает под собой последовательную запись.
                        0
                        «Насколько я понимаю in-memory db vs disk oriented dbs. Дисковые БД в большинстве случаев будут медленнее, чем in-memory… » — на 100% согласен с этим абзацем!

                        «Есть огромное количество in-memory Db» — да! Но некоторые делают это и делают это правильно. Как делать это правильно — как раз написано в статье. Разумеется, по верхам, без деталей.

                        «В всех мне известных нормальных disk oriented БД так же происходит запись сначала в transaction log, что подразумевает под собой последовательную запись.» — Да. Но кроме этого запись происходит еще и в B/B+ дерево. И вот это есть рандомная запись на диск и это есть медленно.
                          0
                          > Как делать это правильно — как раз написано в статье.
                          Правильно? Просто писать transaction log? А после restart ждать вечность, пока индексы опять построятся и данные загружаться в память?

                          > И вот это есть рандомная запись на диск и это есть медленно.
                          Ну она не влияет на саму запись в БД, это все делается отдельным working thread, притом все это может batching.

                          Чтобы меня правильно поняли — я за эту статью, просто хотелось дополнить, так как верно замечено «Разумеется, по верхам, без деталей.». :)
                            –1
                            «Правильно? Просто писать transaction log? А после restart ждать вечность, пока индексы опять построятся и данные загружаться в память? » — не совсем. Дочтите статью до конца. Там где про снимки состояния.

                            «Ну она не влияет на саму запись в БД, это все делается отдельным working thread, притом все это может batching.» — влияет, к сожалению. Потому что все что ушло в лог транзакций, но не записалось в дерево хранится в памяти. Рано или поздно эту память надо сбросить на диск в дерево. Механизма компактификации лога транзакций у дисковых СУБД нет (см. P.S. в моей статье про компактификацию лога транзакций), поэтому, чтобы восстановление не заняло вечности надо данные таки записать в дерево на диске, не дожидаясь даже пока кончится оперативная память. Упомянутый вами батчинг помогает лишь отчасти. Когда у вас идут случайные изменения строк в СУБД (это типичный workload), то батчи-не-батчи, все равно каждый батч надо распихать по разным частям дерева.

                            «Чтобы меня правильно поняли — я за эту статью, просто хотелось дополнить, так как верно замечено «Разумеется, по верхам, без деталей.». :)» Все верно :)
                              0
                              ****************************************
                              Упомянутый вами батчинг помогает лишь отчасти. Когда у вас идут случайные изменения строк в СУБД (это типичный workload), то батчи-не-батчи, все равно каждый батч надо распихать по разным частям дерева.
                              ********************************************

                              Это никак не влияет на время отклика.
                              По коммиту все не записанные данные из буфферного пула лога(память), пишутся ПОСЛЕДОВАТЕЛЬНО в лог-файл.
                              По завершению процесса клиенту сообщается о завершении commit(транзакции).
                              База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы.
                              Это может произойти довольно нескоро и делается это отдельным процессом-потоком.
                              И еще в дерево пишутся не кусочки информации, а страницы, по специальным алгоритмам, удерживающих в памяти часто используемую информацию.
                              Даже для отдельных таблиц можно указать приоритет удерживания их блоков в памяти.

                              Я к тому, что если в сервере есть много памяти, то при желании можно сделать из обычной базы почти In-memory…

                                –1
                                «База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы. » — в общем случае это неверноу утверждение. Например, когда делается 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/
                                  0
                                  Например, когда делается UPDATE, то надо подсчитать rows affected и вернуть это клиенту. Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row

                                  Это ещё зачем (исходим из того что все необходимые для запроса данные закешированы (повезло) и блокировка наложена успешно). Зачем ждать сброса грязных данных для ответа на update??? Строго говоря, тут и записи в REDO дожидаться не обязательно, транзакцию же не закрываем.
                                    –1
                                    Если мы исходим из того, что повезло, то да, ждать не надо. Все будет хорошо. За исключением пп.1,2,3 выше.

                                    В вашем утверждении «База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы. „ не было сказано, что повезло. Оно было сделано безусловно.
                                      0
                                      Не в моём, но я всё равно не улавливаю логику. Если требуемых данных не оказалось в кэше, то их надо прочитать с диска. Зачем ждать запись на диск при выполнении update? И как это связано с подсчётом количества изменённых строк?
                                        0
                                        Записи ждать не надо, вы правы. Но чтение надо сделать, если данных нет в кэше (что вы сами и сказали) — и это рандомное обращение к диску, которое портит всю картину, что, в общем не сильно лучше, если даже дождаться записи.
                                    +2
                                    +++++++++++++++++++++++++++++++
                                    Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row.
                                    ++++++++++++++++++++++++++++++++++++++

                                    Даже дальше читать не стал.
                                    Я вам говорю как это есть в коммерческих СУБД, а не то, что вам представляется.
                                    Изменения делаются только в буфере(в памяти) страниц(копии блоков таблиц и индексов в памяти).
                                    Также делается запись в БУФЕР(память) лога.
                                    По коммиту буфер лога сбрасывается в лог(redo write ahead).
                                    ВСЁ — пользователю сообщается о успешном коммите.
                                    Причем по коммиту сбрасываются данные не только своей транзакции, а всего что было до.

                                    Если закешировать всю таблицу, то не потребуется и чтения блоков с диска при UPDATE.
                                    А вот запись в датафайлы НИКАК не связана с временем отклика.
                                    Это ассинхронный процесс для обеспечения чекпоинтов, которые будут использоваться при восстановлении и обеспечивают моменты времени в которые можно считать, что все блоки из памяти были записаны на диск(датафайлы).
                                      0
                                      Если памяти хватает, чтобы хранить все грязные страницы всегда, тогда вы правы. Я придрался выше к тому, что в общем случае утверждение было неверно. Еще раз, если памяти хватает, то все хорошо. Но все равно будет работать медленнее чем in-memory и потреблять больше памяти, просто потому что in-memory заранее оптимизирована под работу, когда все всегда в памяти.
                                        0
                                        В каком общем случае?
                                        Утверждение верно, почитайте про Write-ahead logging…
                                        перед написанием следующей статьи, то что вы описали в статье всё точно также работает и в обычных базах. И запись в редо-лог и снапшоты(чекпоинты), нет только фазы загрузки базы в память на старте.

                                        Вот этот ваш текст об обычных базах в корне не верен и заморочит не одну неокрепшую голову — «надо реально дождаться записи в табличное пространство»:

                                        ********************************************************
                                        Breslavets
                                        «База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы. »

                                        danikin
                                        — в общем случае это неверноу утверждение. Например, когда делается UPDATE, то надо подсчитать rows affected и вернуть это клиенту. Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row. Причем, это не только запись в индексы, но и чтение из индексов в перемешку. И все это с рандомным перемещением головки, потому что различные row и части индекса, которые изменяются, находятся в разных местах диска.
                                        ***********************************************************************
                                          0
                                          Если есть труба, которая слева широкая, а справа — узкая и в нее втекает слева вода, заполняя все сечение трубы, то какая бы не была длинная эта труба, рано или поздно в нее будет втекать слева ровно столько воды сколько и вытекает справа. Т.е. узость трубы справа будет узким местом и будет влиять на количество воды, которое может втечь в нее в единицу времени слева.

                                          Базе хошь-не-хошь придется дожидаться флаша грязных страниц на диск, потому что не будет хватать памяти, чтобы сохранять в ней грязные изменения. Если только, еще раз повторю, если только вся база целиком не закэширована в памяти. Т.е. в общем случае ваше утверждение остается неверным.
                                            +1
                                            типа выкрутились… :)
                                            Этот текст уже правильный и сильно отличается от исходного, а то меня уже пугало,
                                            что вы там собрались что-то писать про обычные базы.
                                            Но огорчу, описанных проблем не возникает при как я писал адекватном железе, софте и админе. Чекпоинт плавненько идет не надрывая систему.

                                            И тем не менее, то что вы написали можно отнести и к In-memory базам, когда им не хватит памяти…

                                            Кроме того ждемс описания чудесато-шустрого процесса создания чекпоинта, т.е. снапшота.
                                            Как это сделано в In-memory базе без рэндом записей?
                                            Что весь кусок памяти(всю базу) на диск?
                                            Но такое часто не поделаешь.
                                              +1
                                              Повторюсь, не пытаюсь доказать, что из обычной базы можно сделать полный эквивалент базы в памяти.
                                              Можно сделать «почти» в каком-то варианте.

                                              Но читать заблуждения о обычных базах тоже не хочется.
                                              Вам не надо спешить, в том числе и со статьями.
                                                0
                                                Я уже понял, что я кривовато сформулировал. И уважаемая бородатая общественность — любители старых добрых баз — тут же прицепилась к этому. Ну что ж, каждый получает удовольствие по своему.
                                                0
                                                Вы забыли добавить, что еще при адекватных пользователях, которые не создают нагрузку в 100K запросов в секунду :-)

                                                Ибо, если пользователи не такие адекватные, то проблем не возникает только лишь при соответствующей настройке базы, чтобы она все грязные страница флашила путем последовательнорго обхода всей базы, чтобы не упираться в рандомную запись, а это значит, что пока она обходит должно быть место в памяти для хранения всех грязных страниц, что, в свою очередь, при равномерно распределенной нагрузке по всей базе почти неизбежно означает, что нужно в памяти хранить всю копию базы. Я этот тезив в том или ином виде повторяю уже Nый раз, и в ответ слышу лишь про магические хорошие настройки и тд без конкретнго объяснения физике процесса как узкая труба становится широкой.

                                                in-memory базам хватает памяти. Они просто не работают, когда кончается память. Это не повод для гордости. Но это обратная строна медали, с которой надо мириться заранее при проектировании приложения. Ровно также как обычные базы перестают работать при нагрузке хотя бы 1/10 от in-memory баз, даже если все сидит в кэше. И с этим фактом тоже надо мириться заранее при проектировании приложения.

                                                Вест кусок, да на диск. Описал тут в деталах в одном из коментов. И это можно делать часто, ибо это происходит линейно, диск не нагружая, оставляя много IOPS'ов для REDO.
                                                  0
                                                  *************************************
                                                  Ровно также как обычные базы перестают работать при нагрузке хотя бы 1/10 от in-memory баз, даже если все сидит в кэше. И с этим фактом тоже надо мириться заранее при проектировании приложения.
                                                  ***************************************************

                                                  Ну для того их и придумали, в памяти…
                                                  Oracle и Oracle TimesTen In-Memory Database :)

                                                  Кому не надо такой скорости хватит и обычных СУБД.

                                                  Про пользователей не совсем понятно, но по кэшу вам любой админ скажет, что в разогретой базе процент попадания в кэш идет под 100%.(тут могут быть тонкости с этими процентами, но в целом...).
                                                  Т.е. они практически ин-мемори. :)
                                                    0
                                                    К утру сошлись на трех рублях :-)

                                                    В разогретой базе процент попадания в кэш высокий. Вопрос в том, как быстро работает это кэш версус ин-мемори база. Обычно хорошо, если в 10 раз медленнее, как я написал выше. Плюс его разгорев — это отдельная боль, я уже писал про это.
                                                      0
                                                      Не туда подцепил ответ )

                                                      К утру сошлись на трех рублях :-)

                                                      В разогретой базе процент попадания в кэш высокий. Вопрос в том, как быстро работает это кэш версус ин-мемори база. Обычно хорошо, если в 10 раз медленнее, как я написал выше. Плюс его разгорев — это отдельная боль, я уже писал про это.
                                          0
                                          --Правда, будет все равно хуже чем in-memort:

                                          Я не вдаюсь в детали и не утверждаю обратного.
                                          Но отмечаю, что конкретный момент увязки времени отклика и завершения процесса записи информации в базу освещен не верно.

                                          Тут только добавляется время чтения блоков, если их нет в кэше.
                                          Но я специально оговорил, что мы рассматриваем закешированную таблицу/индексы.

                                            0
                                              0
                                              См. мой комент выше. Если закэшировать вообще все и вся, то да.
                                                0
                                                Да вы так и не поняли про запись.

                                                Вам пытаются сказать, что коммерческие СУБД делают изменения таблиц-индексов ВСЕГДА в кэше(в памяти).
                                                Запись по коммиту ведется только в редо-логи.

                                                И запись в табличные пространства не влияет на время отклика в любом случае, так как она производится для измененных блоков во всей базе (любыми транзакциями) асинхронно от конкретной транзакции, а не как вы считаете, специально для конкретной транзакции что-то пишется в табличные пространства по коммиту.
                                                Мы конечно говорим про нормально настроенную базу с адекватным железом и админом.

                                                  0
                                                  Кстати в статье запись тоже производится думаю примерно также и для тех же целей — то что в статье называется снимком(чистый чекпоинт в обычных базах).
                                                  Т.е. измененная информация даже в этих in-memory базах также пишется на диск в табличные пространства как и в обычных базах(независимо от комита в конкретной транзакции), иначе после перезагрузки не будет данных :).

                                                  В целом, по статье, я вижу отличие от обычных баз только в том, что при старте такой базы она полностью «восстанавливается» в память, ну и другие структуры — хотя это неправильный подход — на физическом уровне в обычных базах может быть что угодно.

                                                  В обычных базах мы можем указать таблицы, блоки которых хотим держать по возможности в памяти.
                                                    0
                                                    Снимок можно делать реже или чаще — это никак не влияет на скорость работы IMDB. Это влияет только на скорость восстановления.

                                                    Насчет неправильного подхода — вопрос спорный. Вы можете настроить Oracle или вашу любимую классическую СУБД так, чтобы она заданные таблицы сразу на старте целиком загружала в память, вместе с индексами и с данными и никогда бы их из памяти не убирала и хранила бы их в памяти эффективно с точки зрения потребления памяти, а на также как эти данные представлены на диске? Если можете, то поделитесь, пожалуйста, настройками — я проведу бенчмарки на чтение таких таблиц. Если окажется, что они будут работать по скорости хотя бы рядом с IMDB, то я сниму перед ваши шляпу.
                                                      0
                                                      *****************************************
                                                      Снимок можно делать реже или чаще — это никак не влияет на скорость работы IMDB. Это влияет только на скорость восстановления.
                                                      **************************************************

                                                      Вот, в обычных системах точно также, особенно если вспомнить, что в IMDB может памяти не хватить.
                                                      Ну и опять же при условии адекватности софта-железа-админа :)

                                                      Конечно почти также, иначе не придумывали бы IMDB.
                                                      Может получиться, что процесс записи нагружает хранилище и
                                                      это может сказаться скорости чтений блоков.
                                                      Но всё должно быть сбалансировано под задачу.

                                                      Не понял про «неправильный» подход…
                                                      Я говорил о неправильном вашем понимании шагов, которые выполняет СУБД при DML+commit.

                                                      И всегда подчеркивал, что полную IMDB из обычной не сделаешь.
                                                      Все же от задачи зависит.
                                                      Я, например знаю систему, в которой использовали Oracle In-Memory, а потом поняли, что хватит и обычного Oracle.
                                                      Если база редко перегружается и правильно настроена, то необходимые блоки будут всегда «разогреты»(почти :) ).

                                                        0
                                                        Перечитал про «неправильность» — ясно о чем…

                                                        Я там к тому, что выдвигать физические способы хранения-доступа на первый план не совсем корректно.
                                                        Есть обычные базы со своими запатентованными методами хранения-поиска…
                                                        Или, я например не уверен, что даже то же упомянутое LSM-дерево
                                                        не используется в каких-то обычных базах — почему нет?
                                                        В целом не эта рутина интересна и важна, если именно она конечно не решает проблемы, которые есть в обычных базах.

                                                          0
                                                          Еще раз повторюсь. Если вся база влезла в кэш, то тогда все хорошо. В противном случае аналог снимка (флаг грязных страниц) будет не успевать отрабатывать целиком, пока будут приезжать новые грязные страницы, и в этот момент придется задерживать клтиента пока не завершится флаш. Если вы считаете, что не придется, то куда тогда будут применяться изменения, если память кончилась? Только в REDO?
                                                      0
                                                      Если у вас достаточно памяти, то да. Если недостаточно памяти, то асинхронный процесс в какой-то момент превратится в синхронный, потому что не будет памяти, чтобы сохранять в ней грязные страницы.
                                                        0
                                                        Такого не бывает в коммерческих системах.
                                                        Если пЫонэр какой на коленках что-то наваял… да и продал… да еще и дали всё это «1C'нику админить…
                                                          0
                                                          Это означает, что в вышеуказанных коммерческих системах размеры кэшей или буферных пулов задраны настолько высоко, что для данного паттерна нагрузки то, что я написал выше никогда не случается.
                                              –1
                                              Перечитал еще раз, и увидел еще одно заблуждение по поводу обычных СУБД.
                                              Даже не понял сначала с этой терминологией…

                                              Снимки в IMDB — это аналоги чекпоинтов в обычных базах, ну и бакапы есть разных видов.
                                              Память в адекватной системе не может кончится — специальный процесс постоянно следит за этим, выгружая наименее используемые блоки из кэша.

                                              **************************************************************
                                              Механизма компактификации лога транзакций у дисковых СУБД нет (см. P.S. в моей статье про компактификацию лога транзакций), поэтому, чтобы восстановление не заняло вечности надо данные таки записать в дерево на диске, не дожидаясь даже пока кончится оперативная память.
                                              **********************************************************************

                                              Не надо вам про обычные базы пока статью писать.

                                              Лучше подробнее про IMDB рассказать.
                                              Вот например, можно ли делать кластеры, что делать если потребуется увеличить размер базы.
                                              Как это делается, растет и какие тут тонкости, чем платится и есть ли ограничения?

                                                –1
                                                «выгружая наименее используемые блоки из кэша» — что приводит к рандомной записи на диск. Которой в IMDB нет.

                                                «Механизма компактификации лога транзакций» — уже выше обсуждали, что тут неверно поняли друг друга, разное понимание терминалогии. Под компактификацией в IMDB понимается постоянный сброс полностью всего снимка всей базы данных, который снимает необходимость при восстановлении читать все логи, сделанные раньше снимка. Снимок всей базы у RDBMS не делается, потому что RDBMS не хранится вся в памяти.

                                                «Не надо вам про обычные базы пока статью писать.» — это статья про IMDB. Но сравниваю с RDBMS. Чтобы было понятно тем кто сейчас на них сидит. Я понимаю, что тут сидят все профи по RDBMS. Вопрос только в том до каких нагрузок эти профи их разгоняли и во что эти профи упирались. Если вы на их нагрузках они ни во что не упирались, то не надо думать, что вы супер-профи и все про RDBMS знаете, все адекватно настроили и сидите на вершине мира, и не надо думать, что те, кто уже сидят на IMDB — полные мудаки и не пробовали различные варианты ускорить RDBMS прежде чем перейти на IMDB. Призываю вас сконцентрироваться на том, что для вас новое и познавать, вместо того, чтобы цепляться к каждой букве, строить неверные выводы и триумфировать на этом.

                                                Теперь насчет кластеров. На моем опыте все делается на уровне приложения. Кластеризация на уровне СУБД (как это сделано в couchbase) приводит к излишним тормозам и головняку. Обыяно кластеризуем так, что разделяет разные независимые куски на разные базы и храним их на разных серверах. Рассказывать детали, чем платится и какие ограничения пока не хочу. Сначала все надо в более менее обоснованную статью выдать, сведя все факты, иначе вы выльете поток говна и троллинга, не разобравшись :-)
                                                  –1
                                                  «выгружая наименее используемые блоки из кэша» — что приводит к рандомной записи на диск. Которой в 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.

                                                  терзают смутные сомнения… :)
                                                    0
                                                    У Tarantool есть два движка — memtx (движок по умолчанию — in-memory) и vinyl (дополнительный, не in-memory движок, т.е. он не хранит все данные в памяти и предназначен для use cases, когда все данные в память не влезают).

                                                    Вы считаете, что Vinyl — это in-memory движок? Ну ок, продолжайте считать дальше. И на основании этого заблуждения стройте какие-угодно теории. Стройте, не буду вам мешать. Если вам это доставляет удовольствие :-)
                                                      0
                                                      Так они же вроде как в связке работают и один дополняет другой, или еще и тут «магия»?
                                                      Если Вы говорите исключительно о «in-memory storage engine (memtx)» тогда и для других DB включайте магию (Oracle «Oracle Database In-Memory», Sql Server «In-Memory OLTP» т.д.) говорите и сравнивайте только с аналогичными фичами «данных в памяти».

                                                        0
                                                        «Так они же вроде как в связке работают и один дополняет другой, или еще и тут «магия»?» — не понял вашего вопроса, простите. Сформулируйте, плиз, по другому.

                                                        «Если Вы говорите исключительно о «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 человек, там мой только перевод, ссылка на оригинал в тексте)
                                                          0
                                                          Можно ли заставить IMDB использовать только Vinyl или только Memtx в работе?
                                                          какую магию, вы о чем?

                                                          Когда вы приводите сравнение с «Обычной Базой Данных», то в этой «Обычной Базе Данных» слишком много проблем, по сравнению с IMDB. Основной акцент делается на «что приводит к рандомной записи на диск. Которой в IMDB нет.» и повторяется в разных вариантах.
                                                          Правда, будет все равно хуже чем in-memort:
                                                          1. Будет хуже по пропускной способности на запись, потому что рано или поздно надо записать данные в индексы рандомно.

                                                          Однако вам уже приводили примеры и ссылки, в которых «Обычные Базы Данных» отлично реализуют фунционал IMDB и это является одним из их штатных рабочих режимов. Да ладно… фиг с ним :)

                                                          Менять статью? зачем. Если не некоторые смущающие высказывания в ней и после нее, много людей бы не узнали бы любопытные подробности о этой теме:)
                                                          Так что спасибо :)
                                                            0
                                                            В 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.

                                                            Однако вам уже приводили примеры и ссылки, в которых «Обычные Базы Данных» отлично реализуют фунционал IMDB и это является одним из их штатных рабочих режимов. Да ладно… фиг с ним :)


                                                            Про функционал я вообще в статье ни разу не говорил. Функционала у RDBMS больше чем у IMDB. И это одно из преимуществ RDBMS. Я тут только про производительность.

                                                            Менять статью? зачем. Если не некоторые смущающие высказывания в ней и после нее, много людей бы не узнали бы любопытные подробности о этой теме:)
                                                            Так что спасибо :)


                                                            Вот именно. Я уж лучше переживу неадекватный троллинг, но дам людям новые знания.
                                                    0
                                                    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 не хранится вся в памяти.


                                                    Разные задачи, разные объемы,
                                                    Запись в датафайлы будет вестись даже при достаточном количестве памяти.
                                                    Старт базы будет быстрым.

                                                      0
                                                      Дык в том то и дело, что большая часть того, что вы почему-то считаете новым в статье, таковым не является для обычных СУБД.


                                                      Видимо, вы умеете читать мысли и знаете то, _что_я_считаю_новым_. Ок. Убеждать вас в обратном не вижу смысла, потому что вы лучше меня знаете, что я считаю, и что я не считаю :-)

                                                      Из статьи я узнал нового только использовании 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+ запросов в секунду убивает ее в щи.
                                                        +1
                                                        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 нигде не будет. :)

                                                          0
                                                          Давным давно был СБОС, без всяких оберток.


                                                          Угу. А еще давнее (еще до СБОСа) биллингов не было, и компьютеров не было.

                                                          Базы-обертки-кэши используют довольно часто, при этом ВСЯ информация всё равно хранится в обычных базах.


                                                          Прям ВСЯ и у ВСЕХ во ВСЕХ кейсах? Зуб даете?

                                                          И основная часть кода работает с обычными базами.
                                                          Потому что этого достаточно и с обычными базами кодить привычнее.:)


                                                          Да. Работает — не трожь.

                                                          Кроме того они имеют отлаженную систему резервирования, а этот рынок очень консервативен.


                                                          IMDB тоже имеют. Но рынок консервативный, спору нет.

                                                          Да.

                                                          Интересно, как там «звонки» будут они хранить в IMDB и сколько такая база будет стартовать?


                                                          А сколько у Билайна звонков в сутки? И сколько весит у них один CDR? И что, для биллинга надо все звонки за сутки хранить?

                                                          Так обычно не делают, и дальше обертки на входе системы IMDB не пускают.


                                                          Вас дезинформировали. Делают по разному.

                                                          Т.е. только критичный к производительности модуль заводят на эту промежуточную базу… например те же звонки можно, но только текущая обработка на входе, а потом перемещение в основную базу обработанной информации.


                                                          По началу Билайн так и будет делать. А потом задастся вопросом — а зачем мне основная база-то?

                                                          Ибо IMDB быстренько лопнет по памяти от такого потока.


                                                          Вам вангой надо работать.

                                                          Или есть секретный рецепт?


                                                          Будем секреты по чуть-чуть выдавать. Не все сразу.

                                                          Аналогично, переведет, посмотрим…
                                                          Всё переведут, или как вы писали выше — «Там Oracle был окружен сапописной in-memory»…


                                                          Сделают так, как это будет эффективней Самоцели заменять Оракл на что-то еще — ни у кого нет. Есть экономика и развитие бизнеса.

                                                          Вы точнее формулируйте — уже хотят использовать…
                                                          Или используют на приеме, в какой-то части системы, в качестве быстрого буфера… — да это уже давно в работе, и скорее всего в этом виде и останется в большинстве критичных к хранению данных проектов.


                                                          Ну точно ванга.

                                                          Потому что сам банк или сотовая компания ничего не могут сами поменять.


                                                          Прям ни один банк и ни одна сотовая компания сами прямо НИЧЕГО не могут поменять? Что за бред.

                                                          Вот чей биллинг использует сейчас Билайн?
                                                          Как они могут просто базу поменять, если в Тарантуле, как я понял нет даже нормальной поддержки SQL.
                                                          Скорее всего поменяют ту «обертку» на критичной по нагрузке части.
                                                          Как это и есть сейчас в подобных проектах.


                                                          Пока Tarantool будет оберткой, потом репликой, а там посмотрим.

                                                          Пока везде основной объем информации хранят Oracle и прочие… «тарантулы» только в проектах или на критичной к performance части только на входе для текущей обработки…


                                                          Прям таки ВЕЗДЕ? Я завидую вашей осводомленности обо ВСЕМ и обо ВСЕХ.
                                                            +1
                                                            М-да… столько букв..., я тут и Ванга, и зуб должен давать… и телепат…

                                                            Beeline переходит уже на Tarantool (почитайте новости в Интернете).


                                                            Почитал, в новостях есть что-то о использовании Тарантула в личном кабинете.
                                                            Это как-бы далеко не биллинг.

                                                            Заодно почитал, что Вымпелком меняет биллинг Amdocs, на систему от Ericsson… — и где, ёлы-палы там будет Тарантул?

                                                            Амдокс, кстати, итак использует IMDB с незапамятных времен для тарификации( сейчас IMDB+IMDG чтобы масштабируемость обеспечить), но звонки всё равно хранятся в обычной базе…

                                                            А сколько у Билайна звонков в сутки? И сколько весит у них один CDR? И что, для биллинга надо все звонки за сутки хранить?


                                                            Вопрос ставить надо не о сутках, а о месяцах.
                                                            2 месяца, 6ть…
                                                            Разве клиент не может попросить/(заказать ежемесячно) детализацию по счету?
                                                            Или, что счета никому не надо выставлять в конце месяца с агрегацией по логическим вызовам(локальные, междугородние, международные, ...) скидки считать не надо....?

                                                            Плюс есть гос. требования к времени хранения.

                                                            Вы же вроде как говорили, что участвовали в разработке биллинга для МТС и еще нескольких операторов или тоже личные кабинеты были?

                                                            Прям ни один банк и ни одна сотовая компания сами прямо НИЧЕГО не могут поменять? Что за бред.


                                                            Бред?
                                                            Ну вы жжете.
                                                            Базу может поменять разработчик биллинга/банковской системы в какой-то из своих версий и предложить эту версию кастомеру.

                                                            И это не простая задача даже при смене полноценных RDBMS с полной поддержкой SQL, всё требует проверки и сертификации.

                                                            Даже при смене одной и той же базы на более старшую версию в четвертой цифре (11.2.0.2->11.2.0.4) вопросы будут, а уж если первые менять…
                                                            Конечно, Заказчик может поменять поставщика биллинга, но это опять же не просто смена базы.

                                                            Тут тема исчерпана похоже, почитаю как снимки делаются.
                                                            Хочу отметить, что тема мне интересна, и прошу не воспринимать какие-то
                                                            прямые ответы как наезд, раз уж опубликовали статью — варитесь — вкуснее будете.

                                                              0
                                                              Заодно почитал, что Вымпелком меняет биллинг Amdocs, на систему от Ericsson… — и где, ёлы-палы там будет Тарантул?


                                                              Не все сразу

                                                              Разве клиент не может попросить/(заказать ежемесячно) детализацию по счету?
                                                              Или, что счета никому не надо выставлять в конце месяца с агрегацией по логическим вызовам(локальные, междугородние, международные, ...) скидки считать не надо....?


                                                              Разве нельзя исторические данные, на которые почти нет нагрузки, хранить в RDBMS? Можно. Одно другому-то не мешает.

                                                              Вы же вроде как говорили, что участвовали в разработке биллинга для МТС и еще нескольких операторов или тоже личные кабинеты были?


                                                              Мне не очень понятно ваше пренебрежительное отношение к личным кабинетам. Но я участвовал именно в разработке биллинга в СиБОССе. Писал штуку, которая называлась «Сервер оценки разговоров». Она хранила все в памяти, считала на лету сколько списать, отправляла в онлайне на коммутатор (через Radius, насколько я помню) инфу, сколько можно продолжаться разговор и записывала результат в Oracle. Кстати, в Oracle она писала не синхронно, иначе он не тянул, несмотря на то, что работал на огромных дорогих железках и быстрых дисках, поэтому и баланс абонента (тот который он получал при звонке в кол-центр или на USSD сообщение) обновлялся не синхронно, а несколько секунд спустя, когда Oracle все коммитил. Причем, скажу больше, не просто не синхронно, а еще и многопоточно во много параллельных коннектов, ибо через один коннект Oracle справлялся хуже чем через несколько.

                                                              Хочу отметить, что тема мне интересна, и прошу не воспринимать какие-то
                                                              прямые ответы как наезд, раз уж опубликовали статью — варитесь — вкуснее будете.


                                                              Что я и делаю. Готов слушать любой троллинг, наезды и неадекват, лишь бы за этой щелухой хотя бы иногда проглядывало драгоценое зерно истины и знаний :-)
                                                                +1
                                                                Денис, просматривается некоторый запуг и манипулирования RDBMS-никами своих клиентов.Лишь бы не сократили их как «спецов». Типа билинг повалится, нужна сертификация и прочие «аргументы». Как будто Майл.ру это коленописная компания. Я работал с Oracle. Правда очень давно. Впечатления остались не самые радужные.
                                                                  0
                                                                  Не бойтесь, не повалится биллинг на Тарантуле — его в биллинг пока не пустят.

                                                                  И Oracle многим не нравится, только лучше ничего не придумали в стане RDBMS.
                                                                  40 лет скоро, кстати старичку.
                                                                    0
                                                                    Ok
                                                                      0
                                                                      как 40? по wiki 1979 год выхода
                                                                      0
                                                                      +1
                                                                      +1
                                                                      Мне не очень понятно ваше пренебрежительное отношение к личным кабинетам. Но я участвовал именно в разработке биллинга в СиБОССе.


                                                                      Это не пренебрежение, просто народ был введен в заблуждение.
                                                                      Личный кабинет — это личный кабинет, а биллинг — это совсем другая сложность и стоимость — сами почитайте в Сети, с Эриксоном на $1млрд. контракт заключили на 7 лет.
                                                                      До этого с Амдокс был не хилый контракт.

                                                                      Причем когда я сказал, что Заказчик не может просто так поменять базу в биллинге/банковской системе, с вашей стороны опять был поток, скажем так, недобросовестной мысли.
                                                                      И я не знаю чего тут больше, — незнание того как такие системы сопровождаются или просто было желание закидать шапками,
                                                                      объявив бредом невозможность замены базы заказчиком.

                                                                      До этого вы рассуждали о Тарантул-обертке именно в контексте биллинга для Билайна на первое время,… цитировать не буду, но речь там шла именно о биллинге, о звонках в IMDB.

                                                                      В общем не здорово всё это, и надеюсь вы понимаете, что в существующую систему биллинга воткнуть что-то чужеродное, тем более такое своеобразное как Тарантул силами Заказчика невозможно. А поставщику биллингга это вообще никак не нужно — у него итак используются работа в памяти в онлайн-чарчинг системах, и IMDB и IMDG в текущих версиях(т.е. могли предложить обновить систему....).
                                                                      Совсем другое дело личный кабинет.

                                                                      Писал штуку, которая называлась «Сервер оценки разговоров». Она хранила все в памяти, считала на лету сколько списать, отправляла в онлайне на коммутатор (через Radius, насколько я помню) инфу, сколько можно продолжаться разговор и записывала результат в Oracle.


                                                                      prepaid, Онлайн тарификация, они(СБОСС) её делали позже основной своей постпайд системы…
                                                                      И ключевое тут по теме —
                                                                      «Она хранила все в памяти»…
                                                                      и
                                                                      «записывала результат в Oracle»…
                                                                      Также как это делается в других подобных системах.
                                                                      Спрашивается и чего мы тут буяним? :)

                                                                      Кстати, в Oracle она писала не синхронно, иначе он не тянул, несмотря на то, что работал на огромных дорогих железках и быстрых дисках, поэтому и баланс абонента (тот который он получал при звонке в кол-центр или на USSD сообщение) обновлялся не синхронно, а несколько секунд спустя, когда Oracle все коммитил. Причем, скажу больше, не просто не синхронно, а еще и многопоточно во много параллельных коннектов, ибо через один коннект Oracle справлялся хуже чем через несколько.

                                                                      На винде приложение писали(Visual C++) как основной их тарификатор?

                                                                      У СБОСС проблема в том, что используется ОДНА база на ВСЁ.
                                                                      Т.е. звонки, платежи(банк-касса), клиентская информация, абоненты-услуги, тарифы, начисления, роуминговая информация, номерная емкость, ежемесячная биллинговая информация(счета),… вообще ВСЁ хранится в одной базе. Ладно хранится, оно же всё время дергает базу в разные стороны…
                                                                      Тогда как в подобных системах только для звонков должна быть возможность использования нескольких баз. То что я говорил о адекватности софта-железа-админа…
                                                                      Не знаю делали ли они отдельную базу для prepaid — не думаю.

                                                                      Хотя для большинства не очень больших операторов их postpaid система удобна и проста. Как и BIS питерский.
                                                                        0
                                                                        Пропускаю все что вы написали про мои недобросовесные мысли и про то, что заказчик не может поменять и все остальное про IMDB. У вас есть безусловно опыт тут. Странно, что вы его обобщаете на все и вся. Но это ваше дело :-)

                                                                        prepaid, Онлайн тарификация, они(СБОСС) её делали позже основной своей постпайд системы…
                                                                        И ключевое тут по теме —
                                                                        «Она хранила все в памяти»…
                                                                        и
                                                                        «записывала результат в Oracle»…
                                                                        Также как это делается в других подобных системах.
                                                                        Спрашивается и чего мы тут буяним? :)


                                                                        Есть такая способность у многих людей, начинать спорить по одному вопросу, потом не закрыв первый переходить ко второму, потом приписывать другой стороне спора несуществующие аргументы и открывать по ним третий спор.

                                                                        Но конкретно про СиБОСС. Вот там был а-ля Тарантул. Только самописный. Т.е., если бы они принимали сейчас решение о IMDB, то могли бы легко рассмотреть Тарантул с разработкой логики оценки разговоров на Lua внутри оного и с чтением/записью из/в Оракла прямо изнутри Тарантула + с персистенсом всех промежуточных результатов оценки, чтобы не перезагружать все из Оракла на рестарте. Я там работал, я знаю эту архитектуру. Я знаю архитектуру Тарантула. Это дает мне основания полагать, что он там подходит. У Билайна кейс пока другой, но в эту сторону они тоже могут в теории пойти, я не могу всего вам тут рассказать.

                                                                        На винде приложение писали(Visual C++) как основной их тарификатор?


                                                                        Да. Кажется, callcharge.exe назывался

                                                                        У СБОСС проблема в том, что используется ОДНА база на ВСЁ.
                                                                        Т.е. звонки, платежи(банк-касса), клиентская информация, абоненты-услуги, тарифы, начисления, роуминговая информация, номерная емкость, ежемесячная биллинговая информация(счета),… вообще ВСЁ хранится в одной базе. Ладно хранится, оно же всё время дергает базу в разные стороны…
                                                                        Тогда как в подобных системах только для звонков должна быть возможность использования нескольких баз. То что я говорил о адекватности софта-железа-админа…
                                                                        Не знаю делали ли они отдельную базу для prepaid — не думаю.


                                                                        Отлично. Вы сразу сотню high class разработчиков Oracle и DBA обвинили в некомпетентности. Как легко вы это делаете. Просто пипец )))

                                                                        А ну как разнесите все на несколько баз в их конкретном кейса и чтобы ACID не потерять и чтобы не прийти к перегону кучи трафика между ними.
                                                                          0
                                                                          Пропускаю все что вы написали про мои недобросовесные мысли и про то, что заказчик не может поменять и все остальное про IMDB.

                                                                          Вы же заявили на весь свет, что Билайн меняет базу на Тарантула.
                                                                          С вашей стороны это было совсем нескромное обобщение…
                                                                          И я же еще и обобщаю что-то.

                                                                          Отлично. Вы сразу сотню high class разработчиков Oracle и DBA обвинили в некомпетентности. Как легко вы это делаете. Просто пипец )))

                                                                          А ну как разнесите все на несколько баз в их конкретном кейса и чтобы ACID не потерять и чтобы не прийти к перегону кучи трафика между ними.

                                                                          Ну да, не просто, но может поэтому другие системы и стоят дороже и рынок другой имеют?
                                                                          Думаете «водафоны» всё держат в одной базе?

                                                                          У RDBMS итак проблем с масштабированием хватает, и при таком подходе они усугубляются.

                                                                          Но повторюсь, для большинства российских операторов системы адекватны и
                                                                          гораздо удобнее сложных в сопровождении западных систем.

                                                                          Своеобразности хватает в обоих системах(СБОСС-БИС), например, по каким-то религиозным соображениям в СБОСС вообще не использовались внешние ключи.
                                                                          Как я понял кто-то из топовых разрабов имел проблемы с блокировками и решил, что проще отказаться от FK, чем разбираться в проблеме.
                                                                          Причем даже просто попытка поговорить на эту тему вызывала конкретный праведный гнев у одного из них. :)
                                                                          Видимо крепко декларативная ссылочная целостность кого-то из них огрела.
                                                                          Нет смысла это обсуждать в этой теме…

                                                                            0
                                                                            Вы же заявили на весь свет, что Билайн меняет базу на Тарантула.
                                                                            С вашей стороны это было совсем нескромное обобщение…
                                                                            И я же еще и обобщаю что-то.


                                                                            Цитату можно?

                                                                            Насчет СиБОСС и всего, что вы написали ниже — кто-то масштабирует базу, кто-то окружает ее IMDB-решениями. Говорить, что одно заведомо лучше чем другое — мне кажется, слишком… эм… серьезное обобщение.
                                                                              0
                                                                              Цитату можно?

                                                                              Ну вы конечно мастрер общения…
                                                                              Вот цитата, вы пишите, что в МТС биллинг был окружен самописной IMDB, и тут же добавляете, что Билайн переходит на Тарантула.
                                                                              Речь о биллинге, не?
                                                                              «переходит на Тарантула» <> «меняет базу на Тарантула»?

                                                                              Ну давайте скажите что-нибудь про Вангу или про то, что меня дезинформировали или что у вас там еще в арсенале?

                                                                              Breslavets
                                                                              В то же время, на обычных СУБД работают очень высоко-нагруженные системы.
                                                                              От биллинга в телекоммуникациях, до банковских и платежных систем с реально нешуточными нагрузками и объемами данных.


                                                                              danikin
                                                                              Вы бы цифры привели. Я лично участвовал в разработке биллинга для МТС и других операторов задолго до работы в Mail.Ru.
                                                                              Там Oracle был окружен сапописной in-memory, чтобы справляться с нагрузкой. Beeline переходит уже на Tarantool (почитайте новости в Интернете).


                                                                              кто-то масштабирует базу, кто-то окружает ее IMDB-решениями. Говорить, что одно заведомо лучше чем другое — мне кажется, слишком… эм… серьезное обобщение.

                                                                              Давайте закруглятся, нормального общения у нас не выходит.
                                                                              Тут никто не говорил, что IMDB не имеют своей ниши.
                                                                              В биллинге используют НЕ однy базу(как минимум отдельные базы для звонков — это вроде просто понять?) + IMDB+IMDG для масштабирования на нагрузочной части(тарификация).
                                                                              ВСЕ данные всё равно как правило хранят в обычных СУБД по множеству причин.

                                                                              IMDB не поможет если весь биллинг, вся функциональность(контракты, клиенты, платежи, диллеры, проведение ежемесячного биллинга, звонки, роуминг, ...) свалена в одну RDBMS на серьезных объемах, даже на средних придётся с бубном плясать когда какие-то процессы пересекутся…

                                                                                0
                                                                                Ну вы конечно мастрер общения…
                                                                                Вот цитата, вы пишите, что в МТС биллинг был окружен самописной IMDB, и тут же добавляете, что Билайн переходит на Тарантула.
                                                                                Речь о биллинге, не?
                                                                                «переходит на Тарантула» <> «меняет базу на Тарантула»?


                                                                                Билайн переходит. Пока не Биллинг. Но это только начало.

                                                                                Давайте закругляться, Ок :-)
                                                                                  0
                                                                                  --Билайн переходит. Пока не Биллинг. Но это только начало.

                                                                                  Еще раз, сейчас у них биллинг Amdocs, переходят они на Эриксон.
                                                                                  Ни в одну из этих систем другую базу не дадут втыкать.
                                                                                  Какую-то вспомогательную обработку(как-то личный кабинет — это не биллинг) могут повесить на что угодно.
                                                                            0
                                                                            Но конкретно про СиБОСС. Вот там был а-ля Тарантул. Только самописный. Т.е., если бы они принимали сейчас решение о IMDB, то могли бы легко рассмотреть Тарантул с разработкой логики оценки разговоров на Lua внутри оного и с чтением/записью из/в Оракла прямо изнутри Тарантула + с персистенсом всех промежуточных результатов оценки, чтобы не перезагружать все из Оракла на рестарте. Я там работал, я знаю эту архитектуру. Я знаю архитектуру Тарантула. Это дает мне основания полагать, что он там подходит. У Билайна кейс пока другой, но в эту сторону они тоже могут в теории пойти, я не могу всего вам тут рассказать.

                                                                            Да не в этом дело, что подходит…
                                                                            Устал уже говорить, что это давно используется в других системах.
                                                                            И на место тарантула можно выбрать кучу кандидатов.
                                                                            Проблема в том, что они уже были выбраны давно в системах о которых шла речь.

                                                                              0
                                                                              Устал уже говорить, что это давно используется в других системах.


                                                                              Ну и отлично. IMDB это хорошо, даже в составе Биллинга. Что раньше, если я правильно понял коллег из этого чата, отрицалось намертво. Простите, если я неверно понял.

                                                                              И на место тарантула можно выбрать кучу кандидатов.


                                                                              Конечно.

                                                                              Проблема в том, что они уже были выбраны давно в системах о которых шла речь.


                                                                              Ну да.
                                                                                0
                                                                                Ну и отлично. IMDB это хорошо, даже в составе Биллинга. Что раньше, если я правильно понял коллег из этого чата, отрицалось намертво. Простите, если я неверно понял.

                                                                                Все тут говорили, что где надо там они(IMDB ) и используются, но все данные как правило всё равно хранятся в обычных СУБД, — что вызывало у вас… В том же Билайне, если они покупали(не знаю точно) онлайн тарификацию — есть база в памяти, хотя у них древняя версия системы.
                                                                                Очень интересно, что им там Эриксон наворотит и чем это закончится.

                                                                                  0
                                                                                  Breslavets, Вы займитесь логистикой энергоносителей. Вам биллинг покажется цветочком.
                                                +2
                                                Часто сталкиваюсь с утверждениями, что «Ведь дисковая база данных вся влазит в in-memory кэш, зачем тогда нужны in-memory базы данных вообще; это хайп и маркетинг, всё давно изобретено в тёплых ламповых RDBMS». Для того чтобы парировать это некорректное утверждение, лекция №2 из курса CMU (первая ссылка), на мой взгляд, дает на сегодня самый полноценный и аргументированный ответ.

                                                Корректный ответ состоит в том, что дисковые базы данных не плохие или хорошие сами по себе. Однако, они предназачены для работы с блоковым устройством хранения (block-storage device), коим является SSD и HDD. И это их классовое структурное ограничение. Имено поэтому, даже если вы дадите дисковой базе данных RAM-диск (тем самым потеряв вообще всякую персистентность), заметно быстрее она от этого работать не станет.

                                                Вот скриншот по мотивам работы Стоунбрейкера «OLTP Through the Looking Glass» (слайд из лекции CMU, я думаю что не надо объяснять апологетам дисковых баз данных, кто такой Стоунбрейкер):

                                                image

                                                Слайд показывает, что дисковая база данных выполняет собственно полезную работу 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.
                                                  –2
                                                  Имено поэтому, даже если вы дадите дисковой базе данных RAM-диск (тем самым потеряв вообще всякую персистентность), заметно быстрее она от этого работать не станет.

                                                  Ну как не станет? Смысл то не в этом, а в механизмах работы при том условии если структура и данные находятся в памяти. Хотя я думаю ничего не мешает активным данным вытеснять неактивные на диск по определенной процедуре.

                                                    0
                                                    А можно посмотреть реальные тесты, на основании которых построена эта (безусловно красивая) диаграмма? Нет, я не против того, что именно такой порядок цифр имеет место, просто хочется убедиться, что они взяты не с потолка. Кроме того, немного смущает сосредоточенность этой диаграммы на CPU. Это конечно важный ресурс, но не единственный. Хотелось бы ориентироваться на время выполнения, а не на утилизацию процессора.
                                                      0
                                                      Не можно, нужно: http://nms.csail.mit.edu/~stavros/pubs/OLTP_sigmod08.pdf (ссылка из верхнего — не моего — комментария). Кстати, настаиваю не я, а автор всего этого мувмента — Стоунбрейкер (который, например, автор того, что сейчас является PostgreSQL; просто товарищ очень активный и не стоит на месте, просто наслажлаясь уже имеющимися результатами своего труда).
                                                        0
                                                        All experiments are performed on a single-core Pentium 4 3.2GHz, with 1MB L2 cache, hyperthreading disabled, 1GB RAM, running Linux 2.6

                                                        ну что сказать — актуально :)
                                                          0
                                                          Согласен с вами, актуально! В какой-то мере ядрышко в тестах из статьи иногда даже помощнее, чем типичные ядра, что сегодня имеются в commodity машинах. У рабочей лошадки Skylake i7-6700k даже L2 cache такой же, как у Pentium 4. Или вы предлагаете тезис, что современные процессоры значительно лучше в сравнении с Pentium 4 для дисковых баз данных? Понятно, что многоядерность опять же сильно более полезна для in-memory баз данных, нежели для дисковых. А что такого уникального именно для дисковых?
                                                            +2
                                                            ну запихайте imdb в такой же конфиг. запустите на нем такой же сценарий: 32 таблицы по миллиону записей. 1000 клиентов натравите случайным образом выбирать, удалять, обновлять, добавлять в одной из 32 таблицы.
                                                            покажите цифры по imdb и DiskDB. тогда будет предметный разговор, когда построим такие-же графики.
                                                            А пока все по принципу:
                                                            — давай рельсу возьмем?
                                                            — а зачем?
                                                            — если устанем, рельсу бросим и побежим очень быстро.
                                                            IMDB: лог транзакций на диск пишет? да. свое состояние сливает на диск? да. дисковые операции асинхронные? да. индексы и данные в памяти хранит? да. синхронизация между серверами есть? да.

                                                            DiskDB: лог транзакций на диск пишет? да. свое состояние сливает на диск? да. дисковые операции асинхронные? да. индексы и данные в памяти хранит? да. синхронизация между серверами есть? да.

                                                            Только с кого-то фига, дисковые операции для IMDB «бесплатны», а для DiskDB — прямо дибилы писали, которые только-только с дерева слезли и хвосты у них еще не отпали.
                                                              +1
                                                              Спасибо за наводку с вопросами, — видимо, я не смогу избежать подготовки статьи по мотивам CMU лекции. Соль в том, как DDB оперирует блоками (как работает буферный пул) и к чему это приводит в сравнении с IMDB. Это нетривиальное объяснение, оно не вписывается в один абзац, нужны картинки.

                                                              Тянет на статью :) Но как только это станет понятно (и все DDB так устроены) — странет понятно, о чём весь сыр-бор. Это общий принцип, которому следуют все DDB. И он, конечно, вовсе в корне не о том, что диск ворочает головкой. Это физическая особенность железа. SSD не ворочает головкой, но ситуация там тоже не сахар для DDB. Недавно на хабре была статья, где SQL Server разгоняли суперсовременным NAND сервером в TPC-тестах, добились прироста… +35%. Ну это, как бы, даже не разы. То есть, вовсе не в железе дело, а в принципе работы баз.

                                                              На самом деле, легко подобрать нагрузку, где в IMDB диск станет узким горлышком. Проблема в том, что у DDB эта граница — тысячи транзакций, у IMDB — миллионы.
                                                                0
                                                                Очевидно, что Тарантул и прочие IMDB тоже не глупые люди писали, очевидно по каким-то мотивам и явно сравнивали свой результат с тем «что сделали до нас» что бы подтвердить свое решение.
                                                                Именно в этом «сравнение в сопоставимых режимах и одинаковых тестовых сценариях» и есть самое интересное. Много будет вам благодарных за такую статью.
                                                                Если Вы об этой статье, то там не +35% а поболее.
                                                                Смотря что смотрели:
                                                                Если сравнивать сценарий со временем задержки в 20 мс, то конфигурация с SSD-накопителями увеличила количество транзакций в 7,7 раз.

                                                                это дало преимущество в 10,1 раз по сравнению с HDD-накопителями, а в конфигурации с 24 базами и четырьмя экземплярами SQL Server получили прирост в 10,5 раз.
                                                                  0

                                                                  Мотивы вроде Денис объяснял. Мне интересно как построена система резервирования данных. И есть ли вытеснение контента в случае дефицита RAM.

                                                                    0
                                                                    Tarantool целиком в оперативке. Философия этих решений такова: даже если вы хотя бы допускаете возможность вытеснения на диск (дополнительные переключение контекстов, вход в режим ядра, I/O) дизайне движка, это будет уже другой класс решений, у которого максимальная производительность будет ниже в сравнении с решениями, где вытеснения нет.
                                                                      0

                                                                      Есть еще философия операционных систем, которые допускают свопинг. Вот и интересно: можно ли использовать для этого TNT с некоторой модификацией?

                                                          +1
                                                          Спасибо, дельный документ. Правда не нашёл там именно этой красивой круговой диаграммы, но это не беда. В документе много других, ещё более красивых. Собственно, я уже говорил, что никто не спорит с тем, что у IMDB меньше издержек по управлению данными. Особенно если поотключать логи и отказаться от многопоточности со всякими летчами. Но даже если не отключать. IMDB быстрее. Именно поэтому Oracle встроил её в 12 версию. Oracle Exadata вообще вся на IMDB-ячейках построена. Стоит конечно всё это безобразие дорого.
                                                            0
                                                            Есть тонкости. Отключаем логи — это уже, считай, memcached. В redis, к примеру, лог асинхронный — пишется на диск каждую секунду. В общем, это уже не полноценные замены DiskDB. В Oracle 12c, как я понимаю, встроено in-memory option — не является IMDB как таковой, но является прозрачным колоночно-организованным кешем, который поддерживается в памяти параллельно с основным построчным дисковым хранилищем. Их же TimesTen является полноценной IMDB и, вообще говоря, другой продукт. Есть ещё гибридные решения типа SAP HANA — там row и column одновременно без копий данных, интересное устройство само по себе, которого пока нет у других производителей.
                                                              0
                                                              Является. Туда TimesTen встроена. В Oracle Exadata и Oracle Exalytics, точно, в качестве своеобразного кэша. Скорее всего и в Oracle 12 тоже. Поколоночное сжатие тоже используется. В общем-то для того они TimesTen и купили, чтобы встроить в базу.
                                                                0
                                                                Прикольно, не обновлял эти знания пару лет. Действительно, немного запутанно: 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.
                                                                  0
                                                                  Да, есть такое.
                                                        +2
                                                        Это подавался как один из криериев :) Весьма весомый
                                                        Но, не очень понятно как можно сравнивать продукты предназначенные для разных сценариев работы в специфических сценариях игнорируя другие критерии.
                                                        Если сравниваться, то по всем критериям и желательно с цифрами (вроде все технические люди).Например: По объему обрабатываемых данных, по отказоустойчивость, «цена» каждой операции в одинаковых сценариях, по масштабируемости и т.д. А когда не могут внятно объяснить минусы описываемого решения, преподнося его как «Серебряную пулю», это… как-то «не закончено» выглядит :)
                                                          0
                                                          Эти минусы, кстати, будут нивелированы новым железом. Например, NVM 3d-xpoint от Интел (в DIMM-формфакторе уже в 2017-м году) — это плашки постоянной (неволатильной) памяти объёмом 3 Тб штука, со скоростью чтения порядка DRAM, записи — раз в 5-10 медленнее DRAM. Эта память также является byte-addressable, как и DRAM. То есть, базы данных, ориентированные на block-storage, становятся как бы всё менее актуальными. Через пять лет такое железо будет в рамках нормы уже, и дисковые базы данных совсем отойдут. В стратегии Интел — принести вычисления ближе к данным, минимизируя число слоёв: вместо двух слоёв — постоянного диска и непостоянной памяти — будет просто постоянная память, и её будет много. Блоковые устройства становятся уделом чисто архивных данных.
                                                            +1
                                                            HP's 'Machine' из той же серии. похожим последствиями
                                                              0
                                                              О, таки они её планируют скоро выпустить, круто!
                                                      0
                                                      Но ведь существует вероятность того, что БД ответит об успешном выполнении транзакции, в то время как сама транзакция еще не успеет записаться в файл, и в этот момент БД упадет/упадет сервер?
                                                        0
                                                        Последовательность действий такая:
                                                        1) СУБД получила запрос;
                                                        2) СУБД прочитала данные из RAM, выставила в RAM нужные блокировки и записала транзакцию в журнал;
                                                        3а) СУБД сообщила о выполнении транзакции;
                                                        3б) СУБД изменила данные в RAM и сняла блокировки.
                                                        Пункты 3а и 3б можно выполнять параллельно.

                                                        В какой момент что-то там упадёт?
                                                          0
                                                          Понял. Суть в том, что БД отвечает о выполнении транзакции только после фактический записи в журнал. В этом случае да, надежно, но время выполнения транзакции увеличивается до окончания записи на диск.
                                                            0
                                                            Журнал пишется строго последовательно, желательно большими блоками. Это быстро, очень быстро.
                                                              0
                                                              В тексте статьи было ясно сказано, что у СУБД есть две работы: это «запись транзакций в журнал» и «внесение изменений в БД».

                                                              Запись транзакций в журнал производится так: Сначала транзакции (от разных клиентов) накапливаются в памяти. Потом (или по ходу дела) для накопленных транзакций ставятся блокировки. Затем накопленные транзакции большим блоком пишутся в журнал. И это блок пишется непрерывным куском, поэтому пишется быстро.

                                                              Тут есть тонкость: нельзя накапливать транзакции, которые конфликтуют по блокировкам с более ранними ещё не выполненными транзакциями. Точнее, накапливать их можно, но в отдельной очереди. Тут всё сложно, я затрудняюсь точно сформулировать. Короче, у нас есть ограничение на размер единого блока, который мы пишем в журнал транзакций.

                                                              Но в любом случае, запись в журнал транзакций намного быстрее, чем внесение изменений в БД, расположенную на HDD.
                                                                0
                                                                запись транзакции в сотню байт на hdd проходит даже не на линейной скорости, а быстрее, на грани скорости шины sata, а точнее на скорости работы оперативной памяти кеша, пока он не будет заполнен, но при линейной записи он будет очищаться как раз на скорости линейной записи (т.е. если замерять время записи — оно будет минимальна, до тех пор, пока скорость очистки кеша будет быстрее или равна скорости его заполнения)

                                                                сама же запись в кеш на диске безопасна — при выключении она успеет записаться (за исключением ситуации с бедблоками)
                                                              0
                                                              СУБД не отвечает пока не запишет данные в REDO. Если забыть о всяких новомодных async commit-ах.
                                                              +2
                                                              Начали за здравие, кончили за упокой.
                                                              давайте ненадолго забудем про кеширование, это тема для отдельной статьи
                                                              Как это «забудем»? Кэш — это главное, что есть в традиционных СУБД! Всё же сказанное относительно быстрой записи в REDO остаётся в силе. Именно поэтому его выносят на отдельный диск, а то и на SSD.
                                                              Недостатком этого дерева является необходимость изменять его при каждом меняющем данные запросе
                                                              Всё так, только не файл изменять а 1-2 страницы, опять же, скорее всего, закэшированные (не буду я про кэш забывать, что ещё за глупость?).

                                                              Ну и скромно обходится вниманием вопрос: как быть если данные в оперативную память не лезут? Да, да, можно разнести на разные хосты. А можно писать на диск. Всё от задачи зависит.

                                                              А так статья хорошая, годная.
                                                                +1
                                                                Кэш — это, на самом деле зло. Такое же зло как и наркотик. Хорошо, когда он есть и плохо, когда он кончается, но ты уже подсел. И про это тоже будет отдельная статья. Достаточно сказать вловосочетание «холодный старт», от которого у бывалых админов шевелятся седые волосы на всех местах.

                                                                «Всё так, только не файл изменять а 1-2 страницы» — да. И для этого надо сделать несколько рандомных чтений и записей на диск.

                                                                «Всё так, только не файл изменять а 1-2 страницы, опять же, скорее всего, закэшированные» — и? как закэшированность страниц ускоряет их запись?

                                                                «Ну и скромно обходится вниманием вопрос: как быть если данные в оперативную память не лезут? Да, да, можно разнести на разные хосты. А можно писать на диск. Всё от задачи зависит.» — и это тоже тема отдельной статьи. Хотите все в одну кучу? Сорри, я так не умею. Скажу тут лишь то, что если данные не лезут в RAM, то надо понять, а что мы от них хотим, от данных этих, быстрой обработки или медленной. Если быстрой, то хошь не хошь надо покупать RAM и разносить на разные сервера, тк диск медленный. Если не хотим быстрой, то унести эти данные в обычную СУБД. Зачем использовать микроспоп для заколачивания гвоздей?

                                                                «А так статья хорошая, годная.» — согласен на все 100! :-)
                                                                  0
                                                                  «БД в RAM» предполагает, что RAM достаточно велика, чтобы вместить всю БД. В этом случае вся БД будет закэширована.

                                                                  Холодный старт для «БД в RAM» будет намного ужаснее, чем для обычной СУБД. Просто потому, что надо прочесть всю БД из последнего дампа и потом накатить на неё транзакции.

                                                                  Кстати, дампы БД на диск — тоже не дешёвое удовольствие.
                                                                    +1
                                                                    Да не слишком намного. TimesTen, например нормально стартует. За вполне приемлемое время.
                                                                      +1
                                                                      Вот про это тоже надо делать отдельную статью :) Комментирую тезисно

                                                                      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. Соглашусь с ним. Ибо старт — это просто линейное чтение с диска.
                                                                        0
                                                                        Холодный старт для «БД в RAM» будет намного ужаснее, чем для обычной СУБД.


                                                                        Для этого существуют сервера-реплики.
                                                                          0
                                                                          По моему опыту (да-да, мы криволапые админы, работающие на самом высоконагруженном сервисе в России и все такое) все наоборот.

                                                                          Старт БД в RAM

                                                                          1. Переключаем IP с мастера на реплику
                                                                          2. Делаем мастер репликой
                                                                          3. Новый мастер моментально обслуживает запросы
                                                                          4. Предыдущий мастер в течении часа спокойно стартует

                                                                          Старт БД НЕ В RAM

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

                                                                        Нормально ускоряет. Данные меняются в памяти (и пишутся в REDO), а потом не спеша выгружаются рандомным доступом на диск. Это пока кэша хватает, конечно. В остальном согласен почти полностью.

                                                                        Я ведь чего вспылил? Показалось, что статья следует следующему плану:

                                                                        1. Рассказать всю удобную правду полностью (про скорость REDO), про неудобную (объём RAM) промолчать
                                                                        2. Как доходит до конкурентов (которые и не конкуренты вовсе, а просто про другие задачи), начать аккуратно передёргивать на тему «забудем про кэш» и «при любом изменении меняется всё B-дерево [целиком] [прямо на диске!]»
                                                                        3. Тут юные неокрепшие умы начинают воображать себе всяческие ужасы про традиционные СУБД — PROFIT!

                                                                        Но если я не прав, то конечно извиняюсь. Я и сам IMDB очень даже люблю и уважаю. TimesTen тот же и MySQL Cluster.
                                                                          0
                                                                          «Нормально ускоряет. Данные меняются в памяти (и пишутся в REDO), а потом не спеша выгружаются рандомным доступом на диск. Это пока кэша хватает, конечно. В остальном согласен почти полностью» — а толку-то? Если запись бьет рандомно, то кэшируй-не-кэшируй, все равно кэш надо сбросить на диск не одим бандлом, а кусочками, каждой транзакцией в отдельное место диска, заставляя его двигать головкой (если это HDD).

                                                                          1. Я не сказал дополнительно, что база данных, у которой все данные лежат в памяти, ограничена объемом памяти. Согласен с вами. Скрыл горькую правду. Причем так скрыл, что без вашего зоркого ока-то не раскопали :-) Спасибо!

                                                                          2а. "«забудем про кэш»" — забудем как про страшный сон, я бы сказал.

                                                                          2б. "«при любом изменении меняется всё B-дерево [целиком] [прямо на диске!]»" — не нашел у себя эту цитату. Можете дать скриншот?

                                                                          3. Поделитесь, какик ужасы эти самые умы вообразили? К сожалению, не могу влезть им в голову.

                                                                          Ну вы, по своему правы. Особенно в пункте один :-)
                                                                            +1
                                                                            Ну то что в квадратных скобках, «как бы между строк». Так будут воспринимать неокрепшие умы (по себе знаю). Про кэш — да, когда его нет (как в IMDB) это хорошо (когда нет как в RDBMS, ну типа нет на него памяти — это плохо). Я предлагаю закончить на этом пикировку, об одном ведь в общем-то говорим.
                                                                              +1
                                                                              Я понял. Обвиняюсь в том, что оставил между строк текст, который ваш неокрепший ум воспринял неверно. Искренне сожалею об этом. На будущее буду внимательней читать между строк :-)

                                                                              Давайте закончим. Миру мир. Каждый инструмент для своей работы.
                                                                            +1
                                                                            2. О, нашел: «Недостатком этого дерева является необходимость изменять его при каждом меняющем данные запросе» — изменять его — имеется в виду изменять какой-то из его элементов. Перестраивать все дерево, разумеется не надо. Ну а если мы бы в каком-то бреду решили перестроить все дерево, то следующего предложения не было бы «что может привести к падению производительности из-за произвольного доступа к диску», потому что при перестраивании всего дерева произвольного доступа нет, ибо этот процесс можно организовать последовательно. Но смысле в этом процессе я лично не вижу. Как раз смысл B-дерева в том, чтобы менять его элементы без изменнеия всей структуры.
                                                                              0
                                                                              Да, я об этом. Все это понимаю, но знаю дюжину людей, которые поймут этот пассаж крайне превратно. Об этом и речь.
                                                                                +1
                                                                                Я тоже. Это в нашем менталитете. Везде надо найти негатив. И если не понимают о чем речь, то сразу предполагают худшее :)
                                                                          0
                                                                          Разве кэш на запись у вас отложенный? По нормальному (для надежности) его нельзя отложить даже на 1 мс, а это значит запись мелкими блоками 100 IOPS (на HDD).
                                                                            +1
                                                                            Я так понимаю, что коллега имеет в виду кэш для table space (write back buffer). Т.е. в журнал транзакций пишем сразу, а в table space применяем отложено. Откладывать можно с точки зрения надежности насколько угодно долго — все равно все изменнеия сохраняются в логе и при рестарте считываются и накатываются в table space.
                                                                              0
                                                                              Именно так.
                                                                          0
                                                                          А как «СУБД в оперативной памяти» выполняет запросы, требующие создания больших временных таблиц? Особенно, когда этих запросов много и на все сразу оперативки не хватит?
                                                                            +1
                                                                            Разобью ваш вопрос на два:

                                                                            1. Если цель создания временной таблицы — последовательная обработка данных, которые лежат в других таблицах не последовательно (СУБД так может делать иногда), то тогда для СУБД в оперативной памяти не нужны временные таблицы — она может обращаться к оригинальным таблицам рандомно, ибо память на рандомно работает даже быстрее чем диск последовательно.

                                                                            2. Если цель создания временных таблиц — это что-то боле сложное, например, сортировка или просто промежуточные данные, которые созданы по некоему алгоритму из данных в СУБД, и они больше чем размер оперативной памяти, то… тогда, очевидно, никак. Для этих целей надо делать медленную реплику дисковой СУБД к быстрой in-memory СУБД и там спокойно и неспеша ворочать терабайтами.
                                                                              0
                                                                              2 пункт немного мифический — если промежуточные данные настолько больше исходных, надо всерьёз думать об алгоритмах. По 1-му пункту согласен на 100%.
                                                                                0
                                                                                ЧТД, если пункт 2 мифический, то нам несказанно повезло и мы не будем создавать временные таблицы, расходуя драгоценную память :-)
                                                                                +1
                                                                                Временные таблицы в in-memory СУБД — суть индексы, содержащие ссылки на данные. А по поводу «памяти не хватит» — опять же, повторяющиеся значения заменяются ссылками на словарь (как при сжатии обычных файлов).
                                                                                  0
                                                                                  Для этих целей надо делать медленную реплику дисковой СУБД к быстрой in-memory СУБД и там спокойно и неспеша ворочать терабайтами.
                                                                                  А если неспеша нельзя?
                                                                                  Реальный пример — у меня на сайте есть специфическая страница, на которой есть специфический SQL-запрос, при выполнении которого MySQL создает временный файл размер в 2 ГБ (в рамках примера считаем, что изменить это никак нельзя). Если туда зайдут одновременно 5 посетителей, то потребуется 10 ГБ дискового места. Запаса оперативки такого размера, разумеется, нет. А что в таком случае сделает «СУБД в оперативной памяти»? По идее, ей ничего не мешает иметь аналогичный механизм скидывания временных таблиц на диск. Но вот имеет ли в реальности — не знаю.

                                                                                  Собственно, я не прошу ответа прямо сейчас. Скорее, реквестирую статью на эту тему, если возможно. :)
                                                                                    +1
                                                                                    СУБД в оперативной памяти создаст таблицу указателей на соответствующие вхождения в словаре значений. Если это не какие-то новые значения (допустим, «склеить» две строки — это дорого) а уже существующие (99% всех запросов) — такая операция довольно экономна по памяти.
                                                                                      0
                                                                                      Для этих целей надо делать медленную реплику дисковой СУБД к быстрой in-memory СУБД и там спокойно и неспеша ворочать терабайтами.

                                                                                      А если неспеша нельзя?


                                                                                      По идее, ей ничего не мешает иметь аналогичный механизм скидывания временных таблиц на диск. Но вот имеет ли в реальности — не знаю.


                                                                                      Если не спеша нельзя, то значит репликация в СУБД, где будут ворочаться эти 10Гб не устраивает? Если так, то чем скидывание на диск поможет? :-)

                                                                                      Плюс, давайте рассмотрим ваш кейс. Очень вероятно, что все будет именно так как рассказал коллега в параллельном ответе.
                                                                                  0
                                                                                  Статья конечно, отличная, как и другие из этой серии, danikin спасибо что делитесь этой интересной информацией! Правда не понятно почему статья не оформлена как перевод? https://medium.com/@denisanikin/what-an-in-memory-database-is-and-how-it-persists-data-efficiently-f43868cff4c1#.2af61ukjs Так же поделюсь ссылками на другие статьи по теме: https://medium.com/@denisanikin
                                                                                    0
                                                                                    Не за что! Вам спасибо за высокую оценку! :-)

                                                                                    Эта статья и есть перевод. А как надо было оформить?
                                                                                      +1
                                                                                      Ну так на хабре вроде есть специальный тип статей «перевод» который отличается от обычных плашкой «Перевод», а самое главное ссылкой на оригинал. Чем это удобно — так это тем что можно дальше почитать статьи автора если тема интересна =)
                                                                                        0
                                                                                        Буду иметь в виду. Автор тут я, Денис Аникин, можете погуглить другие мои статьи (Dennis Anikin — если по английски решите почитать) :)
                                                                                    –5
                                                                                    >cat /dev/zero >some_file
                                                                                    >И посмотрите, как быстро увеличивается размер some_file.

                                                                                    Мда, грустно и смешно такое читать.
                                                                                    Если человек ничего не знает про файловый кеш, то какие можно ожидать знания по работе реальных БД?
                                                                                      +2
                                                                                      Утверждается, что команда выше, если ее оставить на достаточно долгое время, будет демонстрировать максимальную скорость работы диска.

                                                                                      Конечно, если вам не важна сохранность изменений после перезагрузки компьютера, т.е. ваша операционная система настроена так, что вся доступная оперативная память используется для write back буферов, то придется подождать какое-то время, пока все эти буфера не наполнятся.

                                                                                      Хотя, в большинстве случаев, даже при таком аггресивном кэшировании записи, ждать придется недолго. Слава богу, память конечная и слава богу наполнится она быстро, потому что работает быстро (перегонка из буфера в памяти приложения в буфера Linux'а большими кусками через системный вызов происходит на моем опыте со скоростью полгига в секунду и выше). После чего пойдет уже реальная запись на диск, которая будет упираться в диск. И диск при такой нагрузке будет работать на максимальной скорости, ибо писать будет строго последовательно и большими кусками. Собственно, эту максимальную скорость вы и увидите по скорости роста файла.

                                                                                      Но хорошо, что есть такие профессионалы как вы, которые грустят, смеются, обличают других, ничего не знающих про файловый кэш, удивляются их знаниям по работе реальных БД и знают как минимум чуть больше чем ничего про файловый кэш. Они-то нам всем сейчас расскажут как все происходит на самом деле.
                                                                                        0
                                                                                        Конечно расскажут ;) Сколько всего понаписано, а грамотно-то было всего-то немного поизучать, как правильно измерять производительность последовательной записи на диск и поменять команду 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 для небольших баз при приличной нагрузке — это как-то странно тоже.
                                                                                          +1
                                                                                          Комментирую ваше сверху вниз

                                                                                          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. У вас вся запись/чтение последовательное. Почитайте все-таки внимательно статью прежде чем осуждать. Ну или так сразу и напишите, не читал, но осуждаю :-)
                                                                                            0
                                                                                            Денис, дождёмся ли мы операционной системы на TNT? Проприетарный язык походу Вы делать не желаете. А зря.
                                                                                              0
                                                                                              Наc и так все бюьт за Lua, а вы говорите проприетарный :-)

                                                                                              Насчет операционки — на нас иногда находят мысли, что если унести какие-то вещи в kernel space для уменьшения переключения контекстов, но мы их гоним от себя и думаем как по другому еще можно уменьшить :-)
                                                                                              –1
                                                                                              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 — это извращение ;)
                                                                                                +2
                                                                                                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 не нужен. Перечитайте — статью — там популярно объяснено, почему не нужен :) Если она не помешается в память, то, возможно, она уже не такая маленькая.
                                                                                                  0
                                                                                                  1. ура
                                                                                                  2. Это все же зависит объема измененных данных в отношении всего объема БД
                                                                                                  3. Индексы точно также лежат в кеше. Oracle вообще пофиг, что там в блоках — данные, индексы или undo. Механизм работы с ними с точки зрения кэширования совершенно одинаков.
                                                                                                  Я верю что in-memory быстрее для какого- набора операций — вопрос, чем при этом приходится жертвовать?
                                                                                                  4. Тогда почему ранее Вы написали, что:
                                                                                                  >Механизма компактификации лога транзакций у дисковых СУБД нет
                                                                                                  5. Так я тоже не фанат, я просто не лезу в то, чего не знаю, но меня задевает, когда, вот, наоборот.
                                                                                                  6. Все так, но это вопрос грамотного тюнинга системы. И, опять же, сохранить надо не миллион изменений, а только актуальную версию измененных данных. Вот, тот же undo, перетирается по кругу, например, в зависимости от выставленного retention.
                                                                                                  7.3 Если это не NoSQL база и есть какие-то индексы, кроме первичных ключей, то никуда от этого не денешься в плане расположения данных. Но, еще раз напишу, что базам все равно, что там в блоках — индексы, данные — алгоритм работы с ними одинаков. Не надо никуда лезть на диски, если все помещается в память.
                                                                                                    0
                                                                                                    По 1 еще:
                                                                                                    Надо только понимать, что реальная запись пойдет не одой операцией в 1g, а порциями, при этом не совсем понятно, какими
                                                                                                    Т.е лучше явно написать что-то вида:
                                                                                                    dd if=/dev/zero of=/root/testfile bs=1024k oflag=dsync
                                                                                                    и наблюдать за ростом файла.
                                                                                                      0
                                                                                                      а в не in-memory записывается в слепок рандомно

                                                                                                      Далеко не всегда верно. Если говорить, например, про Apache Cassandra (внутри LSM tree), то SSTable пишется и/или мержится на диск линейно.

                                                                                                        0
                                                                                                        Да. В контексте этого конкретного обсуждения, если вы читали его, «не in-memory» == «традиционная дисковая СУБД, основанная на B/B+ дереве»

                                                                                                        LSM — это отличная структура данных! И я про это в статье упомянул и даже таблицу нарисовал, поищите выше по слову LSM.
                                                                                                        0
                                                                                                        *******************************************************************************
                                                                                                        6. Да. Но, к сожалению, это не убирает рандомные обращения к диску, которые рано или поздно надо сделать, чтобы сохранить, скажем миллион изменений, которые прямо сейчас сидят в памяти и которым предстоит записаться в различные части диска.
                                                                                                        **********************************************************************************

                                                                                                        Расскажите как ЧАСТО и КАК делается снимок(на диск) в вашей терминологии и как он работает?
                                                                                                        Вот база работает, в шустрой In-memory базе (в памяти) нашлепали изменения в блоках…
                                                                                                        И… очень интересно послушать.
                                                                                                          +1
                                                                                                          Мой типичный кейс с 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. Есть еще несколько реплик для надежности. Они на ровно таком же железе. К ним запросы не идут, они вступают в бой только при проблемах с мастером, когда он отказывает

                                                                                                          Если вы можете при таких же входных данных достигнуть такой же производительности любой классической СУБД, то вы — гений.
                                                                                                            0
                                                                                                            Спасибо за пример, тут конечно хорошо, что запсь на диск снапшота не влияет на работу базы, т.к. чтения идут из памяти.
                                                                                                            Гипотетически может замедлить запись в редо(т.е. commit'ы).
                                                                                                            База конечно небольшая, но учитывая стоимость железа конечно отличный результат.
                                                                                                              0
                                                                                                              Гипотетически может замедлить запись в редо(т.е. commit'ы).

                                                                                                              Не замедляет. Там версии в оперативной памяти создаются. То есть снимок не тормозит OLTP за счёт большего расхода оперативной памяти. Ну и плюс в том что пишется последовательно, в отличии от рандомной записи грязных блоков, конечно.
                                                                                                                0
                                                                                                                Все верно говорите. По сути, есть два параллельных процесса записи на диск, каждый из которых пишет строго последовательно — запись в REDO и запись снимка. Запись снимка можно вести на «всех парах», потому что запись в REDO обычно редко потребляет больше нескольких % от максимальной производительности диска.
                                                                                                                  0
                                                                                                                  На разные диски их развести можно?
                                                                                                                    0

                                                                                                                    На некоторых системах это очень рекомендуют делать. По крайне мере я встречал такие рекомендации, например, для Apache Cassandra и Apache Zookeeper.

                                                                                                                      +1
                                                                                                                      Можно. Но даже при моих нагрузках в 100K+ запросов в секунду одного HDD диска достаточно.
                                                                                                                  0
                                                                                                                  Это он OLTP при таком подходе не тормозит, а запись в редо может.
                                                                                                                  Но конечно на таком объеме это не критично.
                                                                                                                  Запустите копирование двух пусть последовательных файлов на чистом диске одновременно.
                                                                                                                  На активных системах редо выносят на отдельные диски, чтобы не рушить эту последовательную запись, ну и они могу быть сильно нагруженными.
                                                                                                                  Т.к. ВЕСЬ DML проходит через логи.
                                                                                                                  И если у вас они не нагружены, значит больше чтений в базе.
                                                                                                                    0
                                                                                                                    Только лучше не копирование файлов, а копирование из /dev/zero, потому что копирование файла это чтение с диска и запись, а копирование из /dev/zero в файл — это только запись. Запускал. Один файл — 100Mb/s, два файла — по 50Mb/s. Это Linux. Там достаточно оптимально все устроено с точки зрения шаринга ресурсов диска.
                                                                                                                      0
                                                                                                                      Т.е. влияние есть, но в вашей задаче не проблема.
                                                                                                                      А можно разные диски задать для снапшота и редо?
                                                                                                                        0
                                                                                                                        Можно. Но даже при моих нагрузках в 100K+ запросов в секунду одного HDD диска достаточно.
                                                                                                                        0
                                                                                                                        А как он снимок этот пишет на диск, если в базу запись идет постоянно?
                                                                                                                        Метки времени есть у страниц?
                                                                                                                        Не пишет те, у которых метки старше старта снятия снимка?
                                                                                                                        Или полную копию делает и пишет?
                                                                                                                          0
                                                                                                                          А для этого я написал еще одну статью. Вот тут в деталях: https://habrahabr.ru/company/mailru/blog/317150/
                                                                                                                  0

                                                                                                                  Не подскажете, а 100 тысяч запросов каких? Т.е. key-value или более сложные выборки, и если да, то насколько сложные?

                                                                                                                    +1
                                                                                                                    Более менее простые. Или выборки/обновления по первичному/вторичному индексу или Lua-код из, условно, 5-10 строчек, внутри которого один-два подобных запроса.
                                                                                                                      0
                                                                                                                      Если для какого-то запроса нет индекса, и база будет вынуждена сначала выбрать из одного индекса и потом выборку проверить на пересечение с другим индексом, насколько это будет медленнее? Т.е. интересно было бы услышать какие-то сравнительные примеры. Это особенно любопытно в свете озвученной цифры в 100000, ведь это фактически означает 10000 наносекунд на запрос, и это очень маленькая цифра ))
                                                                                                                        +1
                                                                                                                        В базе все пишется внутри на Lua. Вы лукапите в один индекс, находите поле, далее по этому полю лукапите в другой индекс. Все занимает как два обращения по индексу. По времени — плюс-минус как два раза в std::unordered_map сходить в терминах С++ + накладные расходы на сетевой вызов.
                                                                                                                          +1
                                                                                                                          Денис, спасибо за ответы! Пишите ещё и добавляйте по максимуму подробностей, дьявол как известно, прячется в мелочах ))
                                                                                                                            0
                                                                                                                            Спасибо, буду! :-)
                                                                                                              +1
                                                                                                              Ну, хорошо, я считают, что держать маленькую highload БД на HDD — это извращение ;)


                                                                                                              Думаю, Mail.Ru с их нагрузками делают это вовсе не потому, что они представители ЛГБТ или у них денег нет на диски (тем более, что всего-то речь идет о каких-то 8-ми серверах).

                                                                                                              А потому что провели замеры и убедились, что на линейном чтении/записи никакой необходимости в SSD нет, а места для множества журналов WAL на HDD все же побольше/подешевле.
                                                                                                                0
                                                                                                                Все верно. Плюс, мы еще в Mail.Ru принимаем решения не на основе «извращние»/«православие», а на основе каких-то более понятных бизнес-терминов — быстрее/медленнее, дешевле/дороже и тд.
                                                                                                                0
                                                                                                                А InMemory таки объемы вообще не под силу.


                                                                                                                А RDBMS такие скорости не под силу.
                                                                                                                И что?

                                                                                                                Каждому инструменту — свое предназначение.
                                                                                                                Гвозди отверткой забивать невозможно.
                                                                                                              +1
                                                                                                              Появился образ эдакого «папы» по базам данных. С высоты своего огромного опыта работы может использовать фразочки типа «вам квалификация не позволяет?» или подлавливать на терминах типа «вы, наверное, индекс имели в виду?».
                                                                                                              Под конец еще написать: «А вообще, я бы хотел почитать про другое».
                                                                                                              При этом думать, что весь мир вокруг работает так же как у него, типа все по щелкчу пальцев побежали и поменяли HDD на SSD, или написали «скриптик, который пробежится полным чтением и закинет в кэш данные по таблицам-индексам» (это ваще огонь, я считаю). Про закешированность страниц тоже отличный коммент с подсказкой от «папы», вы правда считаете что сказали что-то умное?
                                                                                                                –1
                                                                                                                Да я не против, чтобы люди изобретали свое колесо, лучше прежних колес, особенно если за это платят.
                                                                                                                Только хорошо бы для начала разобраться, и понимать, как работает то, что уже давно придумано.

                                                                                                                >Про закешированность страниц тоже отличный коммент с подсказкой от «папы», вы правда считаете что сказали что-то умное?

                                                                                                                Так кто-то же должен был это сказать, развеять, так сказать, заблуждения автора.

                                                                                                                А какие претензии к скриптам разогрева кеша баз? Первый раз про такое слышите?

                                                                                                                >типа все по щелкчу пальцев побежали и поменяли HDD на SSD

                                                                                                                ну, сравните стоимость замены HDD небольшого объема на SSD и стоимость написания своей собственной RDMS, которая будет отличаться только в том, что скидывает данные на диски не случайным, а последовательным способом.

                                                                                                                  +1
                                                                                                                  Вам никто и не предлагает писать собственную СУБД. Если вы ее напишите, то единственным ее пользователем будете вы сами, поэтому вам лично дешевле остаться на SSD.
                                                                                                                    +1
                                                                                                                    А какие претензии к скриптам разогрева кеша баз? Первый раз про такое слышите?


                                                                                                                    Зачем применять методики из одной (непохожей) СУБД, для СУБД другой?

                                                                                                                    Каждому инструменту — свой способ заточки.
                                                                                                                    В in-memory СУБД разогрев происходит автоматом при рестарте.

                                                                                                                    А чтобы не было простоев — просто используются сервера-реплики.
                                                                                                                    Один уже разогрет и работает, второй в этом момент рестартует.

                                                                                                                      0
                                                                                                                      А как влияет скорость репликации между серверами на «гарантированно в памяти» и какая скорость синхронизации?
                                                                                                                        0
                                                                                                                        А зачем там скорость в репликации-то в данном способе использования?

                                                                                                                        Рабочая разогретая реплика содержит 100% данных.
                                                                                                                        Вторая реплика может при этом стартовать весьма и весьма неспешно — этого никто и не заметит.
                                                                                                                          +1
                                                                                                                          Вроде как очевидно.
                                                                                                                          Если сервер А упал, запросы должны на серевер Б. Сервер А обязан содержать данные, подтвержденные сервером Б (фактически двухфазный комит). Этот двухфазный комит стоит какие-то ресурсов.
                                                                                                                          В противном случае, если Сервер А подтвердил данные, а сервер Б еще не подтвердил их,
                                                                                                                          то после момента переключения Клиент будет пытаться оперировать данными, подтвержденными ТОЛЬКО сервером А о которых сервер Б еще не знает.
                                                                                                                            +1
                                                                                                                            Если у вас есть PITR и WAL никуда не делись, то ничто никуда не теряется.
                                                                                                                              0
                                                                                                                              Только вот изменения должны успеть записаться не только в локальный REDO, но и в REDO на всех репликах. То есть мы не имеем права завершать транзакцию пока реплики не отрапортуют о том, что успешно записали в REDO. То есть во время выполнения транзакции (при наличии синхронных реплик) включаются сетевые издержки на взаимодействие между репликами. Разумеется, можно делать часть реплик или даже все реплики асинхронными. Тогда сетевые издержки включаться не будут.
                                                                                                                        0
                                                                                                                        Согласен на 100%. Ну и потом, разгорев кэша идет вслепую, без информации, что именно надо греть. Греть-то надо данные, которые часто запрашиваются. А узнать кто запрашивается часто можно только после того как запросили. Логи предыдущих запросов (всех!) обычно не хранят и обычно разогрев на основании этих логов не делают. Но даже если уважаемый zhekap это делает, то он с высокой вероятностью получит при разогреве те же рандомные обращения к диску, что и при запросах от пользователя, потому что никто не гарантирует, что горячие данные сведены на диске в одну кучу. В IMDB как раз это гарантируется тем, что все данные в IMDB считаются горячими и все они одним линейным куском быстро зачитываются в память при старте.
                                                                                                                        +1
                                                                                                                        *******************************************
                                                                                                                        Так кто-то же должен был это сказать, развеять, так сказать, заблуждения автора.
                                                                                                                        *****************************************************

                                                                                                                        Сверху вниз читаю,…
                                                                                                                        статья понравилась, но мне непонятно зачем автор начал сравнивать in-memory с обычными, в архитектуре которых у него ну явные пробелы.

                                                                                                                        Лучше бы больше рассказал про особенности — вот про те же снимки, которые как я понял аналог наших чекпоинтов, но каким-то чудными образом меньше нагружают I/O, избегая рэндом-записи.
                                                                                                                          –1
                                                                                                                          Про особенности я рассказал в коменте ниже. Сделаю еще одну статью, чтобы рассказать детали. Насчет обычных баз. Сравнение было приведено с целью, чтобы объяснить, что in-memory работают быстрее обычных и показать каким образом они быстрее. Но, похоже, я наступил на больные мозоли тех, кто всю жизнь работает с обычными СУБД, и кто сопротивляется наступлению новых технологий.
                                                                                                                        +1
                                                                                                                        Согласен с вами! К сожалению, таких пап много. Когда достижений показать нельзя, то остается только сидеть на хабре папствовать :-)
                                                                                                                          +1
                                                                                                                          Часто в таких дискуссиях много полезного узнаешь, по сути очень интересно читать, а авторы своими вопросами много полезной инфы открывают. Мне нравится и вопросы читать и ответы. Не нравится только переход на «вам квалификации не хватило?» — это реально обидно и хочеться ругаться. Для профессионалов это неприемлемо.
                                                                                                                            +1
                                                                                                                            Согласен!

                                                                                                                            Самое любопытное, что извинений за оскорбления не следует.
                                                                                                                              –3
                                                                                                                              Странно извиняться перед автором безграмотной статьи, которому ни разу не стыдно.
                                                                                                                              И я не услышал, что именно, кроме отсутствия квалификации помешало грамотно построить работу с кешэм в MySQL? За что извиняться то?
                                                                                                                                0
                                                                                                                                Странно извиняться перед автором безграмотной статьи, которому ни разу не стыдно.
                                                                                                                                И я не услышал, что именно, кроме отсутствия квалификации помешало грамотно построить работу с кешэм в MySQL? За что извиняться то?


                                                                                                                                Использовать MySQL в данных случаях дороже на 1 миллионо долларов.
                                                                                                                                Вот здесь про это детально написано:
                                                                                                                                Как сэкономить миллион долларов с помощью Tarantool
                                                                                                                                  0
                                                                                                                                  Учитывая все коментарии выше, где безграмотность? Цитату в студию.

                                                                                                                                  Далее, в какую сумму вы, уважаемый, квалифицированный знаток MySQL, оцениваете свои услуги по грамнотной настройке индексов MySQL, чтобы он работал быстрее Тарантула или хотя бы также? Назовите свою цену, я вас найму, срубите легкие деньги.

                                                                                                                                  Скажу более, Percona вас оторвет с руками за любые деньги. Они с вашей помощью ускорят миллионы инстансов MySQL по всему миру до скорости in-memory баз данных и заработают на это миллиарды долларов.

                                                                                                                                  И, наконец, Фейсбук тут же возьмем вас на работу — они выкинут все их кэши и прочие самописные штуки типа Tao или Dragon поверх MySQL и останутся с голым оптимизированным MySQL, работающим быстрее чем in-memory базы данных. Их специалисты, работающие в крупнейших технологических компаниях мира ждут вас с распростертыми объятиями. Странно6 что вы еще там не работаете.
                                                                                                                                    0
                                                                                                                                    Спасибо, конечно, но я несколько другой области тружусь, где NoSQL до сих пор не особо применимы, а используются классические RDBMS.
                                                                                                                                    Речь идет о финансовых данных, биллинг мобильных операторов, карточные процессинг и т.п.
                                                                                                                                    Для FaceBook потерять пару комментов или отобразить их чуть позже — это фигня.
                                                                                                                                    Для всего, что связано напрямую с деньгами такие вещи недопустимы.
                                                                                                                                    Вот и вся разница.

                                                                                                                                    Мне кажется, Вам отлично удаются маркетинговые статьи типа вот этой:
                                                                                                                                    http://www.cnews.ru/news/top/2016-12-05_subd_mailru_tarantool_cherez_tri_nedeli_prevratitsya
                                                                                                                                    И они вполне впечатлят каких-нибудь топ-менеджеров и принесут Вам доходы.
                                                                                                                                    Но тут, по-большей части, технические специалисты и такого рода вещи, конечно, могут вызывать раздражение, так как админы и программисты в большинстве не очень любят маркетологов :)
                                                                                                                                      +1
                                                                                                                                      1. «где NoSQL до сих пор не особо применимы, а используются классические RDBMS» — так примените RDBMS в той области, где безграмотные и криволапые админы, не умеющие написать скриптик прогрева применяют NoSQL. Не уходите от ответа!

                                                                                                                                      2. Опять господин соврамши. Это статья не моя. Это журналисты из cnews. Они понабрались случайных фактов, вырванных из контекста, и сделали статью. Ее финальный вид с нами не согласовали. Оракл мы не собираемся убить через 3 недели альфа-версией SQL — это бред.

                                                                                                                                      3. Хорошо, если это раздражение подкреплено какими-то фактами, а не слепой нелюбовью. Я тоже вас не люблю, вы неприятный человек, скажу прямо, но тем не менее спокойно с вами общаюсь, задаю вопросы по существу, до оскорблений не опускаюсь. И все, чтобы докопаться до истины, которая где-то сильно глубоко засела в вашей голове и не выходит наружу :-)

                                                                                                                                        +1
                                                                                                                                        1. Так я такого не предлагал. Это Вы считаете, что можно поставить две разные технологии в заведомо неравные условия и на основе этого делать какие-то выводы :) Я-то понимаю, что RDBMS — да, очень хреновенько масштабируется. Вот отсюда и надо расписывать преимущества NoSQL, не забывая и минусы. А не с точки зрения работы с дисками или тем, что LMS всегда лучше B-деревьев.

                                                                                                                                        2. Фух, ура, у меня еще пока есть шанс не остаться безработным.

                                                                                                                                        3. Т.е слова «папик, у которого нет достижений» не стоит расценивать, как наивную попытку менять задеть? :)
                                                                                                                                          0
                                                                                                                                          1. В какие неравные условия я поставил и какие выводы я сдалал. Цитату дадите?
                                                                                                                                          2. Я бы не зарекался на вашем месте.
                                                                                                                                          3. Вы даже цитировать не умеете. Я такого не говорил. Я говорил это: «Согласен с вами! К сожалению, таких пап много. Когда достижений показать нельзя, то остается только сидеть на хабре папствовать :-)»
                                                                                                                                        0
                                                                                                                                        Спасибо, конечно, но я несколько другой области тружусь, где NoSQL до сих пор не особо применимы, а используются классические RDBMS.
                                                                                                                                        Речь идет о финансовых данных, биллинг мобильных операторов, карточные процессинг и т.п.


                                                                                                                                        Неужели все сырые данные сразу пишутся в РСУБД непосредственно?

                                                                                                                                        А не используется никаких промежуточных специализированных более быстрых не РСУБД?

                                                                                                                                          0
                                                                                                                                          Я не очень понял термин «сырые данные».

                                                                                                                                          По сути в силу необходимости ACID — да, когда вы расплатились в картой в магазине, то oracle выполнил 3-4 commit в redo.
                                                                                                                                            0
                                                                                                                                            Биллинг, например.
                                                                                                                                            Он же изначально в форме не очень удобной для RDBMS.

                                                                                                                                            К примеру, при звонке при тарификации по времени — разве не имеет разве смысла временно сохранить время начала звонка в другой более специализированной СУБД, чтобы записать в RDBMS просто весь звонок целиком как одну запись. Когда разговор закончится и будет известно и время начала и время конца.

                                                                                                                                            Я имею ввиду нечто подобное под сырыми данными.
                                                                                                                                              0
                                                                                                                                              Ну почему?
                                                                                                                                              Просто пишутся маркеры: начало звонка, конце звонка. двумя записями.
                                                                                                                                              Потом проходит обработка ETL и приведение в более удобоваримую аналитическую форму/кубики.
                                                                                                                                                0
                                                                                                                                                С биллингом попроще в силу того, что если даже база недоступна, то коммутационное оборудование все равно генерит записи и они рано или поздно все равно доедут до базы. Небольшой уход в минус для абонентов вполне допустим.
                                                                                                                                                В момент набора номера в базу вообще ничего не пишется, приложение по номеру примерно оценивает тариф (по закешированной в приложении информации об абоненте и та