Pull to refresh
98
0
Денис Аникин @danikin

User

Send message
Про особенности я рассказал в коменте ниже. Сделаю еще одну статью, чтобы рассказать детали. Насчет обычных баз. Сравнение было приведено с целью, чтобы объяснить, что in-memory работают быстрее обычных и показать каким образом они быстрее. Но, похоже, я наступил на больные мозоли тех, кто всю жизнь работает с обычными СУБД, и кто сопротивляется наступлению новых технологий.
Мой типичный кейс с Tarantool:

1. Размер базы данных 200-300Gb (чистые данные весят при этом где-то 80-90% от этого значения)
2. Размер REDO логов за сутки — 20-50Gb
3. Снимок делается раз в сутки. 200-300Gb сливаются на диск целиком. Это происходит последовательно, не сильно нагружая диск и почти никак не замедляя скорость работы REDO лога
4. Количество чтений у такой базы — обычно порядка 100 тыс в секунду — они сервятся из памяти, не нагружая на 100% даже одно ядро процессора. Количество записей 30-50 тыс в секунду, совсем почти не грузят процессор и грузят диск на единицы процентов (в пике это несколько мегабайт в секунду последовательной записи на диск). Грузят они диск лишь только записью в REDO
5. Все это работает на одном сервере supermicro ценой порядка $2700-3000
6. Есть еще несколько реплик для надежности. Они на ровно таком же железе. К ним запросы не идут, они вступают в бой только при проблемах с мастером, когда он отказывает

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

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

Базе хошь-не-хошь придется дожидаться флаша грязных страниц на диск, потому что не будет хватать памяти, чтобы сохранять в ней грязные изменения. Если только, еще раз повторю, если только вся база целиком не закэширована в памяти. Т.е. в общем случае ваше утверждение остается неверным.
Java достаточно быстрый. Но его встроить внутрь СУБД достаточно сложно. Скорее надо СУБД внутрь Java встраивать :-)
Записи ждать не надо, вы правы. Но чтение надо сделать, если данных нет в кэше (что вы сами и сказали) — и это рандомное обращение к диску, которое портит всю картину, что, в общем не сильно лучше, если даже дождаться записи.
См. мой комент выше. Если закэшировать вообще все и вся, то да.
Если памяти хватает, чтобы хранить все грязные страницы всегда, тогда вы правы. Я придрался выше к тому, что в общем случае утверждение было неверно. Еще раз, если памяти хватает, то все хорошо. Но все равно будет работать медленнее чем in-memory и потреблять больше памяти, просто потому что in-memory заранее оптимизирована под работу, когда все всегда в памяти.
Если мы исходим из того, что повезло, то да, ждать не надо. Все будет хорошо. За исключением пп.1,2,3 выше.

В вашем утверждении «База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы. „ не было сказано, что повезло. Оно было сделано безусловно.
Давайте я постараюсь угадать, что вы имели в виду в своем комментарии. Вы имели в виду, что почему бы не включить huge pages (2Mb по дефолту, или еще больше) и это бы ускорило радикально fork, и убрало бы описываемую в этой статье проблему. Да?
Потому что так устроены деревья. Они не непрерывно лежат в памяти. Почитайте тут: https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B0%D1%81%D0%BD%D0%BE-%D1%87%D1%91%D1%80%D0%BD%D0%BE%D0%B5_%D0%B4%D0%B5%D1%80%D0%B5%D0%B2%D0%BE.

В Тарантуле используются структуры, которые лучше локализованы в памяти чем красно-черные деревья. Можно про них почитать тут: https://habrahabr.ru/company/oleg-bunin/blog/310560/. Но и они не непрерывно лежат в памяти.

Вы, очевидно, знаете о структуре данных, в которой можно хранить деревянный индекс и которая непрерывно лежит в памяти. Можете дать ссылку на описание? Наверное, мы что-то упустили из виду.

Сразу скажу, что дерево, разложенное в массив (по сути, отсортированный массив) — плохая структура. Она, конечно, копируется линейно, но в ней можно за LogN делать поиски, но вставка в нее будет за N.

Ваша ссылка, простите, неактуальна. Там 40Гб/сек они получают при копировании массива в 2 килобайта, потому что он сразу целиком помещается в кэш процессора. Посмотрите внимательней на графики — чем больше размер массива, тем меньше Гб/сек.
Вот именно. Когда-нибудь мы про это напишем, покажем бенчи. Вызовем, разумеется, гнев любителей похапэ :-)
«База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы. » — в общем случае это неверноу утверждение. Например, когда делается 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/
Да, ссылка не туда вообще. Спасибо! Сейчас поправим. Речь про таблицу страниц: https://en.wikipedia.org/wiki/Page_table
1. В какие неравные условия я поставил и какие выводы я сдалал. Цитату дадите?
2. Я бы не зарекался на вашем месте.
3. Вы даже цитировать не умеете. Я такого не говорил. Я говорил это: «Согласен с вами! К сожалению, таких пап много. Когда достижений показать нельзя, то остается только сидеть на хабре папствовать :-)»
1. «где NoSQL до сих пор не особо применимы, а используются классические RDBMS» — так примените RDBMS в той области, где безграмотные и криволапые админы, не умеющие написать скриптик прогрева применяют NoSQL. Не уходите от ответа!

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

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

Я утверждал, что NoSQL это RDBMS? Цитату-то можно в студию?
Согласен на 100%. Ну и потом, разгорев кэша идет вслепую, без информации, что именно надо греть. Греть-то надо данные, которые часто запрашиваются. А узнать кто запрашивается часто можно только после того как запросили. Логи предыдущих запросов (всех!) обычно не хранят и обычно разогрев на основании этих логов не делают. Но даже если уважаемый zhekap это делает, то он с высокой вероятностью получит при разогреве те же рандомные обращения к диску, что и при запросах от пользователя, потому что никто не гарантирует, что горячие данные сведены на диске в одну кучу. В IMDB как раз это гарантируется тем, что все данные в IMDB считаются горячими и все они одним линейным куском быстро зачитываются в память при старте.

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity