Tarantool: как сэкономить миллион долларов на базе данных на высоконагруженном проекте

    Аникин Денис ( danikin, Mail.Ru)


    Денис Аникин

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

    Базы данных – это хранилище, более структурированное, чем файл, и обладающее рядом некоторых фич, которых у файла нет.



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


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



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

    Что обычно в таких случаях делают? Еще один сервер. Это репликация. Т.е., по сути, вы доставляете реплики ровно в таком количестве, чтобы они держали вашу нагрузку.



    Вы всю нагрузку на чтение уводите на реплики. Соответственно, нагрузку на запись вы оставляете на мастере. Эта схема может, в принципе, масштабировать нагрузку на чтение практически до бесконечности.

    Дальше у нас происходит нагрузка на запись.



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

    Какие есть еще идеи?

    Шардинг.



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

    Есть много разных способов шардинга – можно резать по базам данных, можно резать по таблицам, можно резать внутри одной таблицы. Способов – миллион. Каждый использует тот способ, который ему удобней.

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

    Но дальше у вас происходит проблема. Ваша следующая проблема – это ваш босс. Что ему в этом может не нравиться? Вроде как, все работает, все шардируется, реплицируется, но что ему не нравится? Деньги. Ему все нравится, кроме того, что это стоит очень дорого, потому что вы доставляете, доставляете, доставляете сервера, и он за это платит.

    Вы ему говорите: «Чувак, ты не понимаешь, у меня тут технология, у меня тут шардинг, репликация… Оно масштабируется бесконечно – это очень крутая система».

    Он вам говорит: «Да-да, но мы теряем деньги, если так пойдет дальше, у нас просто не будет денег, чтобы покупать сервера баз данных. Нам придется закрыться».

    Что же делать?

    На самом деле, нагрузка на базу данных часто бывает устроена так, что какие-то элементы данных на чтение нагружаются очень-очень сильно – они называются «горячие данные».

    Кэширование – это то, что частично решает нашу проблему.



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

    Но… какая есть проблема? Проблема несогласованности – одна из самых больших проблем, которая есть с кэшем.



    Это самая первая проблема, которая тут же видна.

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



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



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



    Как ни странно, если писать в обратном порядке – сначала в базу, потом в кэш, будет ровно такая же проблема: записали в базу, приложение упало, в кэше старые данные, все работает со старыми данными, кэш перезагрузился, потянул из базы новые данные, как бы другую ветку данных, которые не целостные, которые не соответствуют тем изменениям, которые были сделаны поверх другой копии…

    Т.е. с кэшем есть как минимум две проблемы: нет целостности данных, и вам все еще нужен шардинг.

    Какие есть еще проблемы с кэшем? Какие вы кэшем внесли проблемы в тот момент, когда ваш босс начал сердиться? Проблема такая: кэш – это не база данных.



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

    Теперь по поводу проблемы нецелостности данных. Что с ней сделать? Как сделать так, чтобы данные обновлялись и в кэше и в базе целостно? Умный кэш.



    Что такое умный кэш? На самом деле, многие из вас, скорее всего, это делают – это, по сути, кэш, который сам общается с базой данных. Т.е. это не отдельный демон Memcached, а какой-то ваш самописный демон, который внутри себя все кэширует и сам пишет в базу. Приложение в базу не пишет, оно работает полностью через кэш.



    Это решает проблему нецелостности, потому что кэш сначала пишет в базу, а потом пишет в себя. Если он в базу не записал, отдал ошибку – все хорошо. Это конечно не хорошо, но данные целостные. После того, как кэш записал в базу, он в себя запишет данные обязательно, потому что он пишет в память, такого, чтобы данные не записались в память практически никогда не бывает. Вернее, бывает, когда на сервере бьется память и в этот момент все падает, и все равно вы теряете весь кэш, по крайней мере, целостность данных не теряется.

    Но есть один кейс, когда даже при таком умном кэше данные можно потерять.



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

    Это редкий кейс, но такое тоже бывает. Т.е. умный кэш не решает до конца проблему нецелостности данных. И вам все еще нужен шардинг.



    Шардинг – это когда у вас есть база данных, которая на одном сервере, и вы ее просто режете. Вы ее режете на кусочки и эти кусочки укладываете по разным серверам, физическим серверам. Это уменьшает нагрузку на запись, потому что нагрузка на запись идет на конкретный кусочек. Т.е. у вас, по сути, все CPU, например, всех серверов участвуют в обработке этой нагрузки, а не CPU только одного сервера.

    Шардинг у вас все равно остается, а вы помните, что ваш босс не любит шардинг, потому что это очень дорого, потому что много-много серверов и у каждого еще реплики.

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

    Какая еще очень неприятная проблема с кэшем есть? Холодный старт.



    Это супер неприятная проблема, когда кэш поднимается с нуля, чистый, голый, без данных… Он бесполезен, также как машина, полностью заваленная снегом – в нее вначале нужно залезть, а еще ее нужно завести. Холодный старт полностью убивает кэш, все запросы напрямую летят в базу данных.



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

    Четыре проблемы с кэшем:



    Вопрос: как прогреть кэш? Кэш всегда должен быть прогрет, чтобы он имел смысл. Через базу данных его прогревать как-то не аккуратненько, потому что много-много реплик, и они все его греют-греют – слишком дорого они его греют.

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

     Какой самый простой способ персистента для кэша?



    Это просто dump данных. Т.е., на самом деле, мы каждый раз, может быть, в минуту, или, например, раз в 5 минут дампим весь кэш полностью на диск, прямо целиком. Как вам это решение? Отстой, потому что теряется консистентность. Вы раз в 5 минут дампите, у вас как бы сервер поднимается, и он теряет свое изменение за 5 минут. Через базу данных их прогревать нельзя, и даже непонятно, откуда эти изменения взять. И это не единственная проблема.



    Вторая проблема – это то, что по IOPS’ам будет плохо, т.е. постоянно будете нагружать диск. Дампами, дампами и еще раз дампами, постоянными. Чем вы хотите иметь более целостные данные, тем чаще будете дампить. Какой-то не очень приятный путь.

    Как лучше персистить кэш?

    Лог. Нужно просто вести лог.



    Т.е. зачем нам дампить, давайте вести лог, давайте каждое изменение кэша будет логироваться на диск, каждое.

    Если вы думаете, что это медленно (всегда есть мнение, что кэш – это что-то такое быстрое, а когда там появляется диск, то это становится как-то медленно), так вот, на самом деле, это не медленно, потому что даже самый обычный крутящийся магнитный диск, не SSD, пишет со скоростью 100 Мб/с, последовательно пишет. Если размер транзакции, скажем, 100 байт, то это 1 млн транзакций в секунду. Это неимоверная скорость, которая удовлетворит почти всех присутствующих в этой аудитории, может быть даже меня. Поэтому даже один диск с этой задачей вполне справляется, но есть другая проблема, что этот лог разрастается очень сильно, потому что, например, идет 10 инсертов, потом 10 делитов тех же самых данных, они должны все схлопнуться, а в логе они не схлопываются. Или идет 100 апдейтов одного и того же элемента данных, опять же нужен только последний, а в логе хранятся все. Как эту проблему решить? Сшепшоты делать.



    Нужно соединить два этих метода – Dump и Log воедино. Т.е. мы раз в неделю дампим, или когда нам этого хочется, а все остальное время только пишем лог. В дамп мы еще запоминаем id последней примененной записи из лога или последней записи из лога, которая в этом снепшоте еще есть. И когда у нас сервер перезагружается, мы поднимаем с диска dump, восстанавливаем его в памяти и сверху накатываем тот кусок лога, который после этой записи. Все, кэш восстановлен и прогрет сразу.

    Кстати, этот прогрев происходит быстрее, чем из базы данных. Вот такого рода прогрев при перезагрузке потом полностью попадет в диск, потому что это линейное чтение файла – 100 Мб/с. Даже на магнитных дисках это очень быстро.

    Все, проблема холодного старта решена, но это только одна проблема, к сожалению. Хотя кэш прогрет, есть еще 3 проблемы.



    Давайте подумаем, как решить первые две – проблемы неконсистентности и шардинга?

    Идея использовать кэш как базу данных – это очень правильное направление. Действительно, зачем нам в этом месте наша основная база данных? MySQL или Oracle – зачем она нам нужна? Давайте подумаем.

    Нужна, наверное, для 2-х вещей:

    1. мы считаем, что база данных надежно хранит данные, не как кэш, а надежно, т.е. там, наверное, есть какая-то магия;
    2. то, что в базе данных есть репликация. У кэшей обычно репликации нет. Соответственно, кэш сервера вышел из строя или просто перезагрузился, и пока он не поднимет все с диска, это быстрее, чем прогрев, но все равно будет down time – это тоже плохо, а репликации там нет.

    По первому пункту – надежное хранение. Если разобраться, то что хранит база данных? База данных хранит горячие и холодные данные – это по сути все, что она хранит. Горячие данные – это обычно маленькие-маленькие и очень-очень горячие, которым 10-100 тысяч RPS, а холодные данные – это такие большие и холодные, к ним очень мало обращений.



    Всегда получается так, что холодные данные большие, а горячие – маленькие. Это закон жизни.



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

    Зачем мы делаем все это копирование? Мы можем, наверное, копировать только горячие данные?



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

    И ваш босс все еще злой, потому что у вас все еще есть шардинг.

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

    Репликации нет. Это, конечно, плохо, но давайте подумаем, почему кэш не может быть первичным источником данных? Потому что нет репликации? Хорошо, мы ее сделаем.

    Почему еще кэш не может быть первичным источником данных? Потому что он не обладает свойствами баз данных? Мы тоже можем это сделать, мы можем все эти свойства баз данных поддержать, и кэш будет ими обладать. Помните картинку «Кэш – это не база данных»?



    Кэш может быть базой данных. Он может всеми этими свойствами обладать.

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

    Собственно, что мы и сделали, и назвали эту базу данных Tarantool.



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



    По сути, нам не нужны сейчас все эти сотни серверов с шардингом и с репликами, у нас просто наша задача разделилась,



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



    Тут, в принципе, на слайде все написано – наш путь, через который мы прошли, но факт в том, что для большинства задач были достаточны 2 инстанса всего Tarantool – один мастер, второй – реплика, потому что нагрузка, которая идет на одну из баз данных, на один инстанс, она, скорее всего, обеспечит всю вашу полосу нагрузки, которая шла раньше на весь ваш кластер SQL серверов.



    И еще тут один психологический момент – не очень хочется уходить из уютного мира баз данных в неуютный новый мир кэшей. В базе данных транзакции и т.д. Тогда, когда ваш босс злой, вы доставили кэш и как-то сразу стало неуютно. И как раз Tarantool возвращает этот уют, т.е. он, мало того, что решает проблемы неконсистанси и холодного старта. Он, как бы, возвращает вас в мир баз данных для горячих данных.

    Теперь кейс в почте Mail.ru.



    Кейс был такой: нам нужно было хранить профили пользователей. Профили пользователей – это такие маленькие кусочки информации – от 500 байт до 1 Кб на пользователя. Мы изначально стали для этого дела использовать MySQL. И стали дублировать всю нагрузку на профили, которые у нас до этого лежали в старом хранилище, на чтение и на запись на ферму из MySQL. Мы поставили ферму из 16-ти MySQL, все пошардили заранее и туда пустили нагрузку. И оказалось, что на 1/8 от всей нашей нагрузки эти 16 серверов уперлись в полки. В основном, они уперлись в полку по процессору.



    Мы пытались их тюнить так и сяк, но по факту, все, что мы достигли – это 16 серверов на 1/8 нагрузки, т.е. на весь кластер, на всю нагрузку потребовалось бы 128 MySQL серверов. Мы подумали, что это дороговато – это больше 1 млн. долларов. И мы просто поставили несколько серверов с Tarantool и туда пустили всю нагрузку. В тестовых целях, дублировали. И оказалось, что они без проблем ее тянут целиком. Даже одного сервера было достаточно. Поставили просто 4, потому что мастер, реплика + еще пара, на всякий случай. Мы обычно перезакладываемся всегда по нагрузке.

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



    У нас суммарно в облаке и почте больше 120 инстансов Tarantool, серверов прямо с Tarantool, которые используются для разных фич, для очень большого количества фич. Если бы мы все это хранили в MySQL или в любом другом SQL, то это были бы сотни миллионов долларов, просто, если экстраполировать имеющиеся цифры.

    Мораль моего всего выступления: нужно использовать правильный инструмент, для правильной работы, т.е. нужно использовать базы данных для холодных данных и кэши с персистентом, как Tarantool, для горячих данных. И сэкономить на этом 1 млн. долларов.



    Тут краткое Summary о том, что мы сделали. Мы шардировали, реплицировали, уперлись в деньги, стали кэшировать, потеряли консистенси и еще кое-что… Сделали персистент кэш, это не база данных, но он может быть базой данных, отделили горячие от холодных данных, холодные – в MySQL, горячие – в Tarantool, спасли 1 млн. долларов и, как бонус, получили лучший юзер експириенс, потому что все стало быстрее.

    Контакты


    » anikin@corp.mail.ru
    » danikin
    » Блог компании Mail.ru

    Этот доклад — расшифровка одного из лучших выступлений на конференции разработчиков высоконагруженных систем HighLoad++. Сейчас мы активно готовим конференцию 2016 года — в этом году HighLoad++ пройдёт в Сколково, 7 и 8 ноября.

    В этом году Денис подал заявку под названием "Почему Tarantool такой оптимальный?". Обещается срыв покровов :) Константин Осипов так прокомментировал этот доклад — «он такой быстрый, потому что ни делает НИЧЕГО!» :) Послушаем, поспорим!

    Весь Программный комитет HighLoad++ продолжает дружно рекомендовать платформу Tarantool. Это одна из замечательных наших (российских) разработок и, как минимум, заслуживает внимания.

    Также некоторые из этих материалов используются нами в обучающем онлайн-курсе по разработке высоконагруженных систем HighLoad.Guide — это цепочка специально подобранных писем, статей, материалов, видео. Уже сейчас в нашем учебнике более 30 уникальных материалов. Подключайтесь!

    Конференции Олега Бунина (Онтико) 48,25
    Конференции Олега Бунина
    Поделиться публикацией

    Вакансии компании Конференции Олега Бунина (Онтико)

    Комментарии 56
    • –3
      [offtop]Аббревиатуру в фразе «Why use a DBMS?» я сначала прочитал несколько по-иному :)[/offtop]
      • +1
        прямо на одном дыхании прочитал. Немножко правда прожевали момент, в котором рассказывалось какие свойства БД они сделали в тарантуле, и как, и какой ценой.
        • 0
          Про это они хотят прочитать целый доклад:
          http://www.highload.ru/2016/abstracts/2268.html
        • 0
          Раньше тратили на серверы N-SQL $5000. Переключились на tarantool. Теперь хостер доплачивает нам!!!


          А если серьезно, выглядит все многообещающе. Нужно больше success|fail story, для популяризации продукта.

          • 0
            Были на одном хакатоне от Mail.Ru. Коллеги решили взять на себя часть работы с Tarantool.
            Негативный отзыв: были огорчены. Говорят, неудобно очень. Основные претензии были именно к синтаксису и вообще структуре данных. Нельзя просто взять и положить данные. LUA, везде LUA.
            Позитивный отзыв: tarantool очень годный в плане потребления ЦП и памяти. Самое оно использовать в эмбедед устройствах.

            P.S. Сами они пишут на LUA, но в базах данных это им показалось неудобным.
            • +3
              Можно и без луа. Есть SDK ко всем популярным языкам, которые просто кладут или выбирают данные. Мы понимаем эту проблему и поэтому сейчас на полных парах разрабатываем SQL. Оставайтесь с нами! :-)
        • +3

          Хорошо бы вспомнить еще один очень важный параметр — надежность в широком смысле этого слова.


          Классические СУБД отличаются еще и тем, что им можно доверить важные данные, а что касается NoSQL и прочих хранилищ новой формации...


          • поддерживают ли они атомарные бэкапы?
          • можно ли гарантировать сохранность данных после подтвержденного коммита? В том числе при отказе железа?
          • При каких условиях база может сломаться? как извлечь данные из разломанной базы?
          • возможна ли деградация производительности по каким-либо причинам? Что делать, если наша база внезапно начала работать медленно?

          И прочие неприятные моменты, которые выясняются только при эксплуатации.

          • +2
            Могу пригласить мейлрушных админов в чат. С точки зрения эксплуатации — одна из самых простых СУБД в мире. Бэкапить можно прямо на горячюю, копированием файлов из под базы. Либо через встроенный инструмент создания реплики (по сути — создается реплика и тут же отключается от мастера — вот и бэкап). В обоих случаях бэкап всегда целостный и производительность СУБД во время создания бэкапа не приседает. Целостность гарантируется. Можно включить в настройках fsync, можно выключить — тут ничем от других классических СУБД не отличается. Сломаться — я такого не припомню. Извлечь можно все из логов и из снэпшотов. Более того, если из-за бага в коде в базу пришел плохой коммит, то его можно выкусить из середины. Делается это так — берется старый снэпшот (до коммита) и на него накатываются все логи, с исключением из них плохого коммита. Деградация возможна, если запустить долгоиграющие хранимые процедуры (с пустыми циклами, например). Не делайте так :-)
            • +2

              Опыт подсказывает, что у любой новой технологии есть свои скелеты в шкафу) Из последнего — Кафку раскорячивает, если ей за несколько минут добавить/удалить пару сотен топиков.


              Для дальнейшей дискуссии мне, похоже, все-таки придется прочитать документацию к тарантулу :-) Возможно, скелетами окажутся индексы, констрейнты и сложные запросы (если они вообще поддерживаются)

              • +2
                Будем вам признательны, если найдете и вытащите все скелеты наружу. Мы сами очень сильно заинтересованы их найти и устранить.
                • +1

                  Насчет транзакций. Тарантул вообще поддерживает полноценные транзакции или только атомарную операцию записи в несколько таблиц?


                  Если поддерживает:
                  Тарантул поддерживает только READ_COMMITED? И как обстоят дела с конфликтами записи? Т.е. возьмем типичный пример счетчика: есть две параллельные транзакции, каждая из них выбирает числовое значение из одной и той же строки, увеличивает его на 1 и делает UPDATE.


                  Если транзакция сделает UPDATE, а потом SELECT, она увидит свои изменения?


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

                  • 0
                    Хороший вопрос, спасибо! За полными деталями отсылаю к статье Косте: https://habrahabr.ru/company/oleg-bunin/blog/310560/. Тут могу лишь сказать, что все атомарно и в вашем кейсе одна транзакция будет видеть свои изменения, а другая нет. Все достигается за счет однопоточного выполнения. Но поскольку однопоточное выполнение идет строго в памяти не блокируется на медленном диске, то оно идет настолько быстро, что производительность не просаживается. Вот бенч, где Tarantool держит миллион транзакций в секунду на одном ядре, причем запросы с клиента идут параллельно.
          • +1
            Не совсем понимаю. Если вы сделали кэш а-ля свою кэширующую БД на 100GB, то какое основное отличие от обычной БД, благодаря которому обращение к данным происходит быстрее? Принцип хранения данных? По итоговой схеме становится понятно, что к MySQL обращения происходят более редко за счет того, что ко всем горячим данным они идут в tarantool. Но ведь т.о. большая часть нагрузки теперь падает на него. Цитирую: «Мы разработали специальную базу данных для горячих данных» — из этого понятно только то, что большая часть обращений будет падать на вашу новую бд, которую также придется маштабировать. Можете как-то уточнить?
            • 0
              Посмотрите например вот это или можете сами поискать доклады Константина Осипова он архитектор этой БД и уже есть достаточно много записей его докладов, где он достаточно подробно и на понятном языке рассказывает как устроен tarantool, для каких задач оптимизирован и какие есть плюсы и минусы у этой БД.
              • +1
                Спасибо, прочитал. Понял, что все ~100GB хранятся в RAM. Если честно, то очень сомневаюсь в таком подходе. Ну — во всяком случае не понимаю зачем для этого отдельная БД. У всех современных БД есть подсистема кэширования. Я уж не говорю о том, что на серверах приложения так же можно создавать кэши с репликацией. + не понятно что значит что транзакции выполняются в одном потоке… Если сервер приложения создает пул из ~50 тредов и они будут формировать транзакции, то со стороны БД что будет происходить? Они будут в очередь выстраиваться? Т.е. если в обработке сейчас одна транзакция, то вторая будет в ожидании в любом случае? А если это распределенные транзакции?
                • +2
                  Отвечаю по порядку:

                  1. Да, 100Gb хранятся в памяти. Зуб даю. Могу провести в офис, позвести с продакшн консоли и показать. Пишите в личку anikin@corp.mail.ru — согласуем дату и время прихода.
                  2. Зачем для этого отдельная БД — как раз объясняется в моей статье. Разжевывается даже.
                  3. У всех современных БД есть подсистема кэширования. Тут даже спорить не буду.
                  4. «Я уж не говорю о том, что на серверах приложения так же можно создавать кэши с репликацией». Можно. Кэши в сервере приложений создают те же проблемы, что создают отдельные кэши вне серверов приложений, и эти проблемы описаны в стаье выше. И еще — обычно, сервер приложений не один, их много. Это создает те же проблемы, только в квадрате, в кубе, в N-ой степени (вместо N подставьте количество машин, на которые разбалансирован ваш сервер приложения).
                  5. «Если сервер приложения создает пул из ~50 тредов и они будут формировать транзакции, то со стороны БД что будет происходить? Они будут в очередь выстраиваться? Т.е. если в обработке сейчас одна транзакция, то вторая будет в ожидании в любом случае?». Прекрасный вопрос! Об этом рассказано в докладе Кости Осипова, который Олег Бунин недавно тоже опубликовал на Хабре. Если кратко, то все будет хорошо. Все транзакции полетят в сокет одинм пакетом, далее почти моментально обработаются внутри Тарантула в памяти, без операций ввода-вывода вообще, и далее одним же пакетом применятся на диск, тоже глазом моргнуть не успеете. И транзакций будет выполнено миллион в секунду на самом дохлом серверном железе. Пруф: https://gist.github.com/danikin/a5ddc6fe0cedc6257853
                  6. «А если это распределенные транзакции?» — разжуйте, плиз. Не понимаю суть вопроса.
                  • 0
                    Спасибо за подробный ответ!
                    По поводу шестого пункта — я имел ввиду, поддерживаются ли XA транзакции?
                    • 0
                      Не за что) Готов ответить на любые ваши вопросы :)

                      Насчет шестого — понял теперь. Нативной поддержки нет, но можно реализовать на Lua.
                    • 0
                      2. Зачем для этого отдельная БД — как раз объясняется в моей статье. Разжевывается даже.

                      Нет, ибо не ясно, как вы настраивали эти MySql сервера, на каких данных, на каком железе. Вы туда пихали все терабайты, или только «горячие данные»?
                      А пробовали, например, запустить MySql на полностью in-memory диске? Ну чтобы было честно и чтобы MySql тоже хранила все в памяти. А реплицировала бы на диск.

                      Судя по тому, что рассказали в этой статье, «последовательный лог + сбросы на диск» очень сильно напоминает Cassandra. Почему не взять сразу ее? И прикрутить, например, Spark для запросов. Если все данные помещаются в память, оно должно летать.
                      • +2
                        1. Как конкретно настраивали уже не вспомню. Но вы же понимаете, что миллион транзакций в пике на одном ядре каке Тарантул — MySQL не потянет даже близко как ни настрой.
                        2. Пихали туда одни те же данные, что в Тарантул, т.е. только горячие.
                        3. «А пробовали… » — Может это честно, но это не продакшн решение на мой вкус. После ребута всей этой конструкции вы получите фарш в данных. Но если у вас есть успешный опыт такошо применения MySQL и у вас не было коррапта данных, то я снимаю перед вами шляпу.
                        4. «Почему не взять сразу ее?» — потому что она ни разу не in-memory, сильно медленнее.
              • +2
                Не понятно кто и как управляет распределением холодных и горячих данных, это какой-то внешний процесс или тарантул сам скидывает редко используемые данные в «холодное хранилище»?
                • +3

                  Его 3 раза об этом спрашивали, но он так толком и не ответил… Видимо, в их кейсе не учитывается остывание данных.

                  • +2
                    Я думаю это внешняя логика. Тарантул вряд ли что-то знает о mysql и том какие данные можно смигрировать.
                    • 0
                      Внешняя логика. Работаем над тем, чтобы эта логика стала внутренней.
                      • 0

                        А можно остывающие данные автоматически по каким-то критериям скидывать в vinyl?
                        И что в принципе посоветуете почитать на тему совместного использования memtx и vinyl?

                        • 0
                          Можно через луашку это автоматизировать. Пока best practices мы на эту тему не публиковали. Займемся этим в обозримом будущем.
                    • 0
                      Можете пояснить, чем эта реализация отличается от БД SAP HANA?
                      • 0
                        SAP HANA медленнее и дороже. Можете покапаться в его бенчмарках тут: http://global12.sap.com/solutions/benchmark/sd3tier.epx. 100-300К транзакций как Тарантул на одном ядре процессора он не умеет (а в пике Тарантул и миллион дает: https://gist.github.com/danikin/a5ddc6fe0cedc6257853)
                        • 0
                          Покопался. Там тесты на каких угодно БД кроме HANA

                          Вот что говорит официальный форум SAP http://scn.sap.com/community/s4hana/blog/2015/08/25/all-you-wanted-to-know-about-sap-s4-hana
                          SAP and Intel® engineers jointly tested the scan speed of an SAP HANA database across a variety of Intel CPU processors. These tests achieved results of 3.19 billion symbol scans per second per core. Конечно, сложно сказать что они имелли ввиду под symbol scan.

                          По поводу дороже, вы имеете ввиду стоимость лицензии или железа?
                          • 0
                            И лицензии и железа (железа потому что его банально больше потребуется). Но мы бенчей не проводили, если честно, потому что лицензия SAP, насколько я помню, запрещает публиковать релультаты бенчей.
                      • –1
                        Извините, но по ходу повествования сложилось впечатление, что Вы переизобрели Redis. Есть ли какие-то концептуальные отличия от нее? Например, Ваша БД реляционная?
                        • +2
                          Посмотрите доклад Кости Осипова (если конечно осилите):
                          https://habrahabr.ru/company/oleg-bunin/blog/310560/#first_unread

                          P.S. Ну и другим комментаторам советую, если вам и вправду интересно, что же там «внутри» тарантула.
                          • +1
                            https://www.facebook.com/leo.yuriev/posts/553318381522430?pnref=story
                          • +1
                            А драйвер для Node.js есть?
                            • +1
                              https://github.com/KlonD90/node-tarantool-driver
                          • +2
                            очень интересно, но не оставляет впечатление «каши из топора».
                            В том смысле, что берем кэш, прикручиваем к нему фичи БД, выкидываем девяносто процентов данных в другую «медленную» базу, и он показывает чудеса производительности в качестве БД. И не понятно, толи выигрыш за счёт замечательной архитектуры, толи за счёт выигрыша по объему. Правда используют хранение данных в памяти, а не на диске, что может дать выигрыш в скорости.
                            И как отметили, интересно было бы почитать, как происходит разбивка данных на горячие и холодные.
                            • +2
                              «И не понятно, толи выигрыш за счёт замечательной архитектуры,» — за счет ее, родимой. Мы просто более оптимально используем CPU и память. CPU, потому что Тарантул изначально заточен, чтобы выжимать все соки из CPU, в отличие от традиционных дисковых баз. Память, потому что Тарантул in-memory, и поэтому каждый бит памяти экономим — это было сразу заложено в архитектуру. Про это как раз в деталях объяснено в докладе Кости Осипова: https://habrahabr.ru/company/oleg-bunin/blog/310560/.

                              Разбивка пока происходит руками. В целом, это не сложно. Работаем над автоматическим решением. Если хотите, можем в личке пообщаться anikin@corp.mail.ru — посоветую вам как можно в ваших кейсах разбить горячие и холодные данные.
                              • 0
                                Если вы используете msgpack нельзя говорить о том, что Вы каждый бит памяти экономите. Есть покруче форматы. Ну или были…
                                • 0
                                  Опенсорс на то и опенсорс. Каждый может контрибьютить. Вы большой эксперт по структурам данных. Так присылайте нам pull request в Tarantool с его переделкай под более правильные форматы.
                                  • 0
                                    Я не большой эксперт по структурам, но и не маленький. Денис, я расскажу такой случай. Когда-то я пользовался одним программным продуктом известной фирмы. И мне не очень нравилось как он работает в некоторых моментах. Я решил разобраться и разобрался. Потом я решил его качественно улучшить и улучшил.
                                    Мой нестандартный подход сильно отличался от существующих и принятых в этой индустрии на тот момент.
                                    Потом я решил продать решение этой фирме или тем кто купит. Приехал, показал. Они посмотрели. Вникли. Сказали: Гуд!, но мы у вас его не купим. Я спросил: Почему? Ответ был такой — у нас есть своё решение. Я больше не стал рыпаться. Все фирмы так себя ведут. И искренне думаю, что Майл.ру не исключение…
                                    • +1
                                      Я про остальные фирмы наслышан тоже. Но в Mail.Ru нет синдрома «not invented here».

                                      Дайте, пожалуйста, ссылку на исходники базы данных, которая

                                      а) работает быстрее Тарантула и/или имеет лучший memory footprint (со ссылками на бенчи, с открытым исходным кодом бенчей, с инструкцией как запустить, с инструкцией как теструемые системы установить и настроить)
                                      б) аналогична Тарантула по функционалу

                                      И, если а) и б) окажутся правдой + для выяснения этой правды мне хватит день моего времени, то я бы с удовольствием взял бы вас на работу на огромную зарплату и перевел бы все в Почте@Mail.Ru/Облаке@Mail.Ru с Tarantool на вашу новую базу данных.
                                      • 0
                                        Тарантул весьма неплох. Я вижу чего там нет даже не залазя в «потроха», а только общаясь с Вами. Вы не реагируете на ключевые фразы. Я не занимаюсь базами данных с 95 года. Относительно тнт. Мне не нравится использование Lua и не очень нравится msgpack. Но я понимаю почему Вы их используете. Мне нравится JSONNET. Почему вы не копаете в этом направлении? Я не вижу ни одного чела в их группе от Mail.Ru. Это неправильно. Если захочу, то Вы возьмете меня безо всяких предварительных условий:)))
                                        • +2
                                          «Мне нравится JSONNET. Почему вы не копаете в этом направлении?» — если вы расскажите причины покопать в этом направлении кроме той, что он вам нравится, то почему бы и нет, покопаем

                                          «Я не занимаюсь базами данных с 95 года» — наша команда, вся до одного, начала заниматься базами данных уже после 95 года. Видимо, поэтому они не используют best practices от <95 года. Но мы ребята открытые, готовы учиться всему новому, в т.ч. хорошо забытому старому.

                                          «Если захочу, то Вы возьмете меня безо всяких предварительных условий:)))» — разумеется. Будем ждать, пока вы захотите.
                            • 0
                              Тут, в принципе, на слайде все написано – наш путь, через который мы прошли, но факт в том, что для большинства задач были достаточны 2 инстанса всего Tarantool – один мастер, второй – реплика, потому что нагрузка, которая идет на одну из баз данных, на один инстанс, она, скорее всего, обеспечит всю вашу полосу нагрузки, которая шла раньше на весь ваш кластер SQL серверов.

                              Не совсем понял это утверждение, ведь у тарантула инстансы не вертикально масштабируемые. В соседнем посте Костя Осипов пишет:
                              Мы, все равно, говорим, что будем шардировать данные, т.е. у нас горизонтальное масштабирование – это норма, поэтому мы даже не пытаемся сделать так, чтобы база данных работала эффективно на одной машине.

                              Т.е. у него идёт совсем другой посыл – вы всё равно вырастите настолько, что вам нужен будет шардинг, поэтому даже чтобы загрузить свой 32-ядерный сервер, поставьте туда несколько инстансов тарантула.
                              • 0
                                Противоречие меня и Кости не вижу. Можете разжевать?
                                • 0
                                  Когда я говорю 2 инстанса, то я имею в виду 2 инстанса, которые будут работать именно на двух ядрах. Два — потому что надо fault tolerance. Т.е. не надо в большинстве случаев даше шардировать даже в пределах одной машины. В целом же, для Tarantool шардинг в пределах одной и не одной машины не отличается.
                                  • +1
                                    Я имел ввиду, что при гипотетической миграции с кластера SQL серверов на tarantool, шардить базу всё равно придётся и инстансов тарантула будет больше двух.
                                    • +1
                                      Если данные физически не влезут на две машины, тогда да, надо горизонтально масштабриовать, добавлять ее машин и инстансов Тарантула хотя бы по одному на машину. Тут пойнт в том, что пока данные влезают на одну машину вам для большинства задач одного ядра будет достаточно и шардить ничего не надо.
                                      • +1
                                        Т.е. данные влезают на одну машину, одного ядра тарантулу достаточно, чтобы всё обработать, а SQL базам понадобился кластер серверов с шардингом?
                              • 0
                                ОК, и чем это лучше того же Redis или другой NoSQL-базы, если таки лучше?
                                • 0
                                  https://medium.com/@denisanikin/tarantool-vs-redis-38a4041cc4bc
                                  • 0
                                    ОК, спасибо.
                                    В двух словах – не нашёл существенных плюсов.
                                    Скрипты – а зачем они, если это просто кеш-база для горячих данных? Нам тут важна скорость, а не вынести часть логики ещё куда-нибудь за пределы приложения. Разве что может быть несколько актуально для многосерверных систем (сеть же медленнее памяти и прочих ресурсов сервера?). Кому это нужно – вариант, по мне же пусть кеш остаётся кешем.
                                    Немного не понял про снимки и лог. Что такое WAL и чем плох AOF? В моём случае AOF с регулярными bgrewrite и резервной копией rdb (причём всё автоматизировано) более чем достаточно. И поднимается после сбоя из того же AOF. Единственный плюс, который я вижу – это если у вас таки умеет правильно загружаться со снепшота и поверх накатывать лог с какой-то точки – холодный старт быстрее.
                                    Что касается SQL, индексов и пр. – это всё только усложняет систему и снижает производительность. Каждое такое новшество повышает требования и сложность синхронизации и persistency. Сначала SQL, потом индексы, потом процедуры с триггерами – и получим ещё одну БД. Сюдаже идея про скрипты.
                                    Размер. Превышение размера легко решается системным swap. Если делать какую-то умную логику хранения на диске – снова начнётся то же разделение данных на горячие и супер-горячие, потом снова захочется супер-горячие отдельно вынести и всё пойдёт по кругу. Кстати, в Redis, кажется, тоже уже что-то такое планировали. И опять же это логику усложняет.
                                    Понятно, многое сейчас базируется чисто на моих конкретных use-cases и требованиях, плюс это сразу в архитектуру заложили (преимущественная статика в реляциооной БД, горячая динамика – в Redis), но для меня это пока очередной велосипед плюс качественный маркетинг.
                                    Но посмотрим, что будет дальше. В любом случае, желаю успехов.
                                    • +1
                                      В указанной мною статье человек рассказал чем ему Tarantool милее Redis на его собственном кейсе. Давайте лучше ваш конкретный кейс разберем. Без кейса обсуждать какая СУБД лучше — сродни онанизму.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое