Comments 56
[offtop]Аббревиатуру в фразе «Why use a DBMS?» я сначала прочитал несколько по-иному :)[/offtop]
прямо на одном дыхании прочитал. Немножко правда прожевали момент, в котором рассказывалось какие свойства БД они сделали в тарантуле, и как, и какой ценой.
Раньше тратили на серверы N-SQL $5000. Переключились на tarantool. Теперь хостер доплачивает нам!!!
А если серьезно, выглядит все многообещающе. Нужно больше success|fail story, для популяризации продукта.
Были на одном хакатоне от Mail.Ru. Коллеги решили взять на себя часть работы с Tarantool.
Негативный отзыв: были огорчены. Говорят, неудобно очень. Основные претензии были именно к синтаксису и вообще структуре данных. Нельзя просто взять и положить данные. LUA, везде LUA.
Позитивный отзыв: tarantool очень годный в плане потребления ЦП и памяти. Самое оно использовать в эмбедед устройствах.
P.S. Сами они пишут на LUA, но в базах данных это им показалось неудобным.
Негативный отзыв: были огорчены. Говорят, неудобно очень. Основные претензии были именно к синтаксису и вообще структуре данных. Нельзя просто взять и положить данные. LUA, везде LUA.
Позитивный отзыв: tarantool очень годный в плане потребления ЦП и памяти. Самое оно использовать в эмбедед устройствах.
P.S. Сами они пишут на LUA, но в базах данных это им показалось неудобным.
Хорошо бы вспомнить еще один очень важный параметр — надежность в широком смысле этого слова.
Классические СУБД отличаются еще и тем, что им можно доверить важные данные, а что касается NoSQL и прочих хранилищ новой формации...
- поддерживают ли они атомарные бэкапы?
- можно ли гарантировать сохранность данных после подтвержденного коммита? В том числе при отказе железа?
- При каких условиях база может сломаться? как извлечь данные из разломанной базы?
- возможна ли деградация производительности по каким-либо причинам? Что делать, если наша база внезапно начала работать медленно?
И прочие неприятные моменты, которые выясняются только при эксплуатации.
Могу пригласить мейлрушных админов в чат. С точки зрения эксплуатации — одна из самых простых СУБД в мире. Бэкапить можно прямо на горячюю, копированием файлов из под базы. Либо через встроенный инструмент создания реплики (по сути — создается реплика и тут же отключается от мастера — вот и бэкап). В обоих случаях бэкап всегда целостный и производительность СУБД во время создания бэкапа не приседает. Целостность гарантируется. Можно включить в настройках fsync, можно выключить — тут ничем от других классических СУБД не отличается. Сломаться — я такого не припомню. Извлечь можно все из логов и из снэпшотов. Более того, если из-за бага в коде в базу пришел плохой коммит, то его можно выкусить из середины. Делается это так — берется старый снэпшот (до коммита) и на него накатываются все логи, с исключением из них плохого коммита. Деградация возможна, если запустить долгоиграющие хранимые процедуры (с пустыми циклами, например). Не делайте так :-)
Опыт подсказывает, что у любой новой технологии есть свои скелеты в шкафу) Из последнего — Кафку раскорячивает, если ей за несколько минут добавить/удалить пару сотен топиков.
Для дальнейшей дискуссии мне, похоже, все-таки придется прочитать документацию к тарантулу :-) Возможно, скелетами окажутся индексы, констрейнты и сложные запросы (если они вообще поддерживаются)
Будем вам признательны, если найдете и вытащите все скелеты наружу. Мы сами очень сильно заинтересованы их найти и устранить.
Насчет транзакций. Тарантул вообще поддерживает полноценные транзакции или только атомарную операцию записи в несколько таблиц?
Если поддерживает:
Тарантул поддерживает только READ_COMMITED? И как обстоят дела с конфликтами записи? Т.е. возьмем типичный пример счетчика: есть две параллельные транзакции, каждая из них выбирает числовое значение из одной и той же строки, увеличивает его на 1 и делает UPDATE.
Если транзакция сделает UPDATE, а потом SELECT, она увидит свои изменения?
Транзакции, содержащие и селекты, и апдейты, должны сильно просаживать производительность тарантула, т.к. однопоточный менеджер транзакций будет ждать окончания открытой транзакции?
Хороший вопрос, спасибо! За полными деталями отсылаю к статье Косте: https://habrahabr.ru/company/oleg-bunin/blog/310560/. Тут могу лишь сказать, что все атомарно и в вашем кейсе одна транзакция будет видеть свои изменения, а другая нет. Все достигается за счет однопоточного выполнения. Но поскольку однопоточное выполнение идет строго в памяти не блокируется на медленном диске, то оно идет настолько быстро, что производительность не просаживается. Вот бенч, где Tarantool держит миллион транзакций в секунду на одном ядре, причем запросы с клиента идут параллельно.
Не совсем понимаю. Если вы сделали кэш а-ля свою кэширующую БД на 100GB, то какое основное отличие от обычной БД, благодаря которому обращение к данным происходит быстрее? Принцип хранения данных? По итоговой схеме становится понятно, что к MySQL обращения происходят более редко за счет того, что ко всем горячим данным они идут в tarantool. Но ведь т.о. большая часть нагрузки теперь падает на него. Цитирую: «Мы разработали специальную базу данных для горячих данных» — из этого понятно только то, что большая часть обращений будет падать на вашу новую бд, которую также придется маштабировать. Можете как-то уточнить?
Посмотрите например вот это или можете сами поискать доклады Константина Осипова он архитектор этой БД и уже есть достаточно много записей его докладов, где он достаточно подробно и на понятном языке рассказывает как устроен tarantool, для каких задач оптимизирован и какие есть плюсы и минусы у этой БД.
Спасибо, прочитал. Понял, что все ~100GB хранятся в RAM. Если честно, то очень сомневаюсь в таком подходе. Ну — во всяком случае не понимаю зачем для этого отдельная БД. У всех современных БД есть подсистема кэширования. Я уж не говорю о том, что на серверах приложения так же можно создавать кэши с репликацией. + не понятно что значит что транзакции выполняются в одном потоке… Если сервер приложения создает пул из ~50 тредов и они будут формировать транзакции, то со стороны БД что будет происходить? Они будут в очередь выстраиваться? Т.е. если в обработке сейчас одна транзакция, то вторая будет в ожидании в любом случае? А если это распределенные транзакции?
Отвечаю по порядку:
1. Да, 100Gb хранятся в памяти. Зуб даю. Могу провести в офис, позвести с продакшн консоли и показать. Пишите в личку anikin@corp.mail.ru — согласуем дату и время прихода.
2. Зачем для этого отдельная БД — как раз объясняется в моей статье. Разжевывается даже.
3. У всех современных БД есть подсистема кэширования. Тут даже спорить не буду.
4. «Я уж не говорю о том, что на серверах приложения так же можно создавать кэши с репликацией». Можно. Кэши в сервере приложений создают те же проблемы, что создают отдельные кэши вне серверов приложений, и эти проблемы описаны в стаье выше. И еще — обычно, сервер приложений не один, их много. Это создает те же проблемы, только в квадрате, в кубе, в N-ой степени (вместо N подставьте количество машин, на которые разбалансирован ваш сервер приложения).
5. «Если сервер приложения создает пул из ~50 тредов и они будут формировать транзакции, то со стороны БД что будет происходить? Они будут в очередь выстраиваться? Т.е. если в обработке сейчас одна транзакция, то вторая будет в ожидании в любом случае?». Прекрасный вопрос! Об этом рассказано в докладе Кости Осипова, который Олег Бунин недавно тоже опубликовал на Хабре. Если кратко, то все будет хорошо. Все транзакции полетят в сокет одинм пакетом, далее почти моментально обработаются внутри Тарантула в памяти, без операций ввода-вывода вообще, и далее одним же пакетом применятся на диск, тоже глазом моргнуть не успеете. И транзакций будет выполнено миллион в секунду на самом дохлом серверном железе. Пруф: https://gist.github.com/danikin/a5ddc6fe0cedc6257853
6. «А если это распределенные транзакции?» — разжуйте, плиз. Не понимаю суть вопроса.
1. Да, 100Gb хранятся в памяти. Зуб даю. Могу провести в офис, позвести с продакшн консоли и показать. Пишите в личку anikin@corp.mail.ru — согласуем дату и время прихода.
2. Зачем для этого отдельная БД — как раз объясняется в моей статье. Разжевывается даже.
3. У всех современных БД есть подсистема кэширования. Тут даже спорить не буду.
4. «Я уж не говорю о том, что на серверах приложения так же можно создавать кэши с репликацией». Можно. Кэши в сервере приложений создают те же проблемы, что создают отдельные кэши вне серверов приложений, и эти проблемы описаны в стаье выше. И еще — обычно, сервер приложений не один, их много. Это создает те же проблемы, только в квадрате, в кубе, в N-ой степени (вместо N подставьте количество машин, на которые разбалансирован ваш сервер приложения).
5. «Если сервер приложения создает пул из ~50 тредов и они будут формировать транзакции, то со стороны БД что будет происходить? Они будут в очередь выстраиваться? Т.е. если в обработке сейчас одна транзакция, то вторая будет в ожидании в любом случае?». Прекрасный вопрос! Об этом рассказано в докладе Кости Осипова, который Олег Бунин недавно тоже опубликовал на Хабре. Если кратко, то все будет хорошо. Все транзакции полетят в сокет одинм пакетом, далее почти моментально обработаются внутри Тарантула в памяти, без операций ввода-вывода вообще, и далее одним же пакетом применятся на диск, тоже глазом моргнуть не успеете. И транзакций будет выполнено миллион в секунду на самом дохлом серверном железе. Пруф: https://gist.github.com/danikin/a5ddc6fe0cedc6257853
6. «А если это распределенные транзакции?» — разжуйте, плиз. Не понимаю суть вопроса.
Спасибо за подробный ответ!
По поводу шестого пункта — я имел ввиду, поддерживаются ли XA транзакции?
По поводу шестого пункта — я имел ввиду, поддерживаются ли XA транзакции?
2. Зачем для этого отдельная БД — как раз объясняется в моей статье. Разжевывается даже.
Нет, ибо не ясно, как вы настраивали эти MySql сервера, на каких данных, на каком железе. Вы туда пихали все терабайты, или только «горячие данные»?
А пробовали, например, запустить MySql на полностью in-memory диске? Ну чтобы было честно и чтобы MySql тоже хранила все в памяти. А реплицировала бы на диск.
Судя по тому, что рассказали в этой статье, «последовательный лог + сбросы на диск» очень сильно напоминает Cassandra. Почему не взять сразу ее? И прикрутить, например, Spark для запросов. Если все данные помещаются в память, оно должно летать.
1. Как конкретно настраивали уже не вспомню. Но вы же понимаете, что миллион транзакций в пике на одном ядре каке Тарантул — MySQL не потянет даже близко как ни настрой.
2. Пихали туда одни те же данные, что в Тарантул, т.е. только горячие.
3. «А пробовали… » — Может это честно, но это не продакшн решение на мой вкус. После ребута всей этой конструкции вы получите фарш в данных. Но если у вас есть успешный опыт такошо применения MySQL и у вас не было коррапта данных, то я снимаю перед вами шляпу.
4. «Почему не взять сразу ее?» — потому что она ни разу не in-memory, сильно медленнее.
2. Пихали туда одни те же данные, что в Тарантул, т.е. только горячие.
3. «А пробовали… » — Может это честно, но это не продакшн решение на мой вкус. После ребута всей этой конструкции вы получите фарш в данных. Но если у вас есть успешный опыт такошо применения MySQL и у вас не было коррапта данных, то я снимаю перед вами шляпу.
4. «Почему не взять сразу ее?» — потому что она ни разу не in-memory, сильно медленнее.
Не понятно кто и как управляет распределением холодных и горячих данных, это какой-то внешний процесс или тарантул сам скидывает редко используемые данные в «холодное хранилище»?
Можете пояснить, чем эта реализация отличается от БД SAP HANA?
SAP HANA медленнее и дороже. Можете покапаться в его бенчмарках тут: http://global12.sap.com/solutions/benchmark/sd3tier.epx. 100-300К транзакций как Тарантул на одном ядре процессора он не умеет (а в пике Тарантул и миллион дает: https://gist.github.com/danikin/a5ddc6fe0cedc6257853)
Покопался. Там тесты на каких угодно БД кроме 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.
По поводу дороже, вы имеете ввиду стоимость лицензии или железа?
Вот что говорит официальный форум 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.
По поводу дороже, вы имеете ввиду стоимость лицензии или железа?
Извините, но по ходу повествования сложилось впечатление, что Вы переизобрели Redis. Есть ли какие-то концептуальные отличия от нее? Например, Ваша БД реляционная?
А драйвер для Node.js есть?
очень интересно, но не оставляет впечатление «каши из топора».
В том смысле, что берем кэш, прикручиваем к нему фичи БД, выкидываем девяносто процентов данных в другую «медленную» базу, и он показывает чудеса производительности в качестве БД. И не понятно, толи выигрыш за счёт замечательной архитектуры, толи за счёт выигрыша по объему. Правда используют хранение данных в памяти, а не на диске, что может дать выигрыш в скорости.
И как отметили, интересно было бы почитать, как происходит разбивка данных на горячие и холодные.
В том смысле, что берем кэш, прикручиваем к нему фичи БД, выкидываем девяносто процентов данных в другую «медленную» базу, и он показывает чудеса производительности в качестве БД. И не понятно, толи выигрыш за счёт замечательной архитектуры, толи за счёт выигрыша по объему. Правда используют хранение данных в памяти, а не на диске, что может дать выигрыш в скорости.
И как отметили, интересно было бы почитать, как происходит разбивка данных на горячие и холодные.
«И не понятно, толи выигрыш за счёт замечательной архитектуры,» — за счет ее, родимой. Мы просто более оптимально используем CPU и память. CPU, потому что Тарантул изначально заточен, чтобы выжимать все соки из CPU, в отличие от традиционных дисковых баз. Память, потому что Тарантул in-memory, и поэтому каждый бит памяти экономим — это было сразу заложено в архитектуру. Про это как раз в деталях объяснено в докладе Кости Осипова: https://habrahabr.ru/company/oleg-bunin/blog/310560/.
Разбивка пока происходит руками. В целом, это не сложно. Работаем над автоматическим решением. Если хотите, можем в личке пообщаться anikin@corp.mail.ru — посоветую вам как можно в ваших кейсах разбить горячие и холодные данные.
Разбивка пока происходит руками. В целом, это не сложно. Работаем над автоматическим решением. Если хотите, можем в личке пообщаться anikin@corp.mail.ru — посоветую вам как можно в ваших кейсах разбить горячие и холодные данные.
UFO just landed and posted this here
Опенсорс на то и опенсорс. Каждый может контрибьютить. Вы большой эксперт по структурам данных. Так присылайте нам pull request в Tarantool с его переделкай под более правильные форматы.
UFO just landed and posted this here
Я про остальные фирмы наслышан тоже. Но в Mail.Ru нет синдрома «not invented here».
Дайте, пожалуйста, ссылку на исходники базы данных, которая
а) работает быстрее Тарантула и/или имеет лучший memory footprint (со ссылками на бенчи, с открытым исходным кодом бенчей, с инструкцией как запустить, с инструкцией как теструемые системы установить и настроить)
б) аналогична Тарантула по функционалу
И, если а) и б) окажутся правдой + для выяснения этой правды мне хватит день моего времени, то я бы с удовольствием взял бы вас на работу на огромную зарплату и перевел бы все в Почте@Mail.Ru/Облаке@Mail.Ru с Tarantool на вашу новую базу данных.
Дайте, пожалуйста, ссылку на исходники базы данных, которая
а) работает быстрее Тарантула и/или имеет лучший memory footprint (со ссылками на бенчи, с открытым исходным кодом бенчей, с инструкцией как запустить, с инструкцией как теструемые системы установить и настроить)
б) аналогична Тарантула по функционалу
И, если а) и б) окажутся правдой + для выяснения этой правды мне хватит день моего времени, то я бы с удовольствием взял бы вас на работу на огромную зарплату и перевел бы все в Почте@Mail.Ru/Облаке@Mail.Ru с Tarantool на вашу новую базу данных.
UFO just landed and posted this here
«Мне нравится JSONNET. Почему вы не копаете в этом направлении?» — если вы расскажите причины покопать в этом направлении кроме той, что он вам нравится, то почему бы и нет, покопаем
«Я не занимаюсь базами данных с 95 года» — наша команда, вся до одного, начала заниматься базами данных уже после 95 года. Видимо, поэтому они не используют best practices от <95 года. Но мы ребята открытые, готовы учиться всему новому, в т.ч. хорошо забытому старому.
«Если захочу, то Вы возьмете меня безо всяких предварительных условий:)))» — разумеется. Будем ждать, пока вы захотите.
«Я не занимаюсь базами данных с 95 года» — наша команда, вся до одного, начала заниматься базами данных уже после 95 года. Видимо, поэтому они не используют best practices от <95 года. Но мы ребята открытые, готовы учиться всему новому, в т.ч. хорошо забытому старому.
«Если захочу, то Вы возьмете меня безо всяких предварительных условий:)))» — разумеется. Будем ждать, пока вы захотите.
Тут, в принципе, на слайде все написано – наш путь, через который мы прошли, но факт в том, что для большинства задач были достаточны 2 инстанса всего Tarantool – один мастер, второй – реплика, потому что нагрузка, которая идет на одну из баз данных, на один инстанс, она, скорее всего, обеспечит всю вашу полосу нагрузки, которая шла раньше на весь ваш кластер SQL серверов.
Не совсем понял это утверждение, ведь у тарантула инстансы не вертикально масштабируемые. В соседнем посте Костя Осипов пишет:
Мы, все равно, говорим, что будем шардировать данные, т.е. у нас горизонтальное масштабирование – это норма, поэтому мы даже не пытаемся сделать так, чтобы база данных работала эффективно на одной машине.
Т.е. у него идёт совсем другой посыл – вы всё равно вырастите настолько, что вам нужен будет шардинг, поэтому даже чтобы загрузить свой 32-ядерный сервер, поставьте туда несколько инстансов тарантула.
Противоречие меня и Кости не вижу. Можете разжевать?
Когда я говорю 2 инстанса, то я имею в виду 2 инстанса, которые будут работать именно на двух ядрах. Два — потому что надо fault tolerance. Т.е. не надо в большинстве случаев даше шардировать даже в пределах одной машины. В целом же, для Tarantool шардинг в пределах одной и не одной машины не отличается.
Я имел ввиду, что при гипотетической миграции с кластера SQL серверов на tarantool, шардить базу всё равно придётся и инстансов тарантула будет больше двух.
UFO just landed and posted this here
Sign up to leave a comment.
Tarantool: как сэкономить миллион долларов на базе данных на высоконагруженном проекте