Comments 56
Раньше тратили на серверы N-SQL $5000. Переключились на tarantool. Теперь хостер доплачивает нам!!!
А если серьезно, выглядит все многообещающе. Нужно больше success|fail story, для популяризации продукта.
Негативный отзыв: были огорчены. Говорят, неудобно очень. Основные претензии были именно к синтаксису и вообще структуре данных. Нельзя просто взять и положить данные. LUA, везде LUA.
Позитивный отзыв: tarantool очень годный в плане потребления ЦП и памяти. Самое оно использовать в эмбедед устройствах.
P.S. Сами они пишут на LUA, но в базах данных это им показалось неудобным.
Хорошо бы вспомнить еще один очень важный параметр — надежность в широком смысле этого слова.
Классические СУБД отличаются еще и тем, что им можно доверить важные данные, а что касается NoSQL и прочих хранилищ новой формации...
- поддерживают ли они атомарные бэкапы?
- можно ли гарантировать сохранность данных после подтвержденного коммита? В том числе при отказе железа?
- При каких условиях база может сломаться? как извлечь данные из разломанной базы?
- возможна ли деградация производительности по каким-либо причинам? Что делать, если наша база внезапно начала работать медленно?
И прочие неприятные моменты, которые выясняются только при эксплуатации.
Опыт подсказывает, что у любой новой технологии есть свои скелеты в шкафу) Из последнего — Кафку раскорячивает, если ей за несколько минут добавить/удалить пару сотен топиков.
Для дальнейшей дискуссии мне, похоже, все-таки придется прочитать документацию к тарантулу :-) Возможно, скелетами окажутся индексы, констрейнты и сложные запросы (если они вообще поддерживаются)
Насчет транзакций. Тарантул вообще поддерживает полноценные транзакции или только атомарную операцию записи в несколько таблиц?
Если поддерживает:
Тарантул поддерживает только READ_COMMITED? И как обстоят дела с конфликтами записи? Т.е. возьмем типичный пример счетчика: есть две параллельные транзакции, каждая из них выбирает числовое значение из одной и той же строки, увеличивает его на 1 и делает UPDATE.
Если транзакция сделает UPDATE, а потом SELECT, она увидит свои изменения?
Транзакции, содержащие и селекты, и апдейты, должны сильно просаживать производительность тарантула, т.к. однопоточный менеджер транзакций будет ждать окончания открытой транзакции?
1. Да, 100Gb хранятся в памяти. Зуб даю. Могу провести в офис, позвести с продакшн консоли и показать. Пишите в личку anikin@corp.mail.ru — согласуем дату и время прихода.
2. Зачем для этого отдельная БД — как раз объясняется в моей статье. Разжевывается даже.
3. У всех современных БД есть подсистема кэширования. Тут даже спорить не буду.
4. «Я уж не говорю о том, что на серверах приложения так же можно создавать кэши с репликацией». Можно. Кэши в сервере приложений создают те же проблемы, что создают отдельные кэши вне серверов приложений, и эти проблемы описаны в стаье выше. И еще — обычно, сервер приложений не один, их много. Это создает те же проблемы, только в квадрате, в кубе, в N-ой степени (вместо N подставьте количество машин, на которые разбалансирован ваш сервер приложения).
5. «Если сервер приложения создает пул из ~50 тредов и они будут формировать транзакции, то со стороны БД что будет происходить? Они будут в очередь выстраиваться? Т.е. если в обработке сейчас одна транзакция, то вторая будет в ожидании в любом случае?». Прекрасный вопрос! Об этом рассказано в докладе Кости Осипова, который Олег Бунин недавно тоже опубликовал на Хабре. Если кратко, то все будет хорошо. Все транзакции полетят в сокет одинм пакетом, далее почти моментально обработаются внутри Тарантула в памяти, без операций ввода-вывода вообще, и далее одним же пакетом применятся на диск, тоже глазом моргнуть не успеете. И транзакций будет выполнено миллион в секунду на самом дохлом серверном железе. Пруф: https://gist.github.com/danikin/a5ddc6fe0cedc6257853
6. «А если это распределенные транзакции?» — разжуйте, плиз. Не понимаю суть вопроса.
По поводу шестого пункта — я имел ввиду, поддерживаются ли XA транзакции?
2. Зачем для этого отдельная БД — как раз объясняется в моей статье. Разжевывается даже.
Нет, ибо не ясно, как вы настраивали эти MySql сервера, на каких данных, на каком железе. Вы туда пихали все терабайты, или только «горячие данные»?
А пробовали, например, запустить MySql на полностью in-memory диске? Ну чтобы было честно и чтобы MySql тоже хранила все в памяти. А реплицировала бы на диск.
Судя по тому, что рассказали в этой статье, «последовательный лог + сбросы на диск» очень сильно напоминает Cassandra. Почему не взять сразу ее? И прикрутить, например, Spark для запросов. Если все данные помещаются в память, оно должно летать.
2. Пихали туда одни те же данные, что в Тарантул, т.е. только горячие.
3. «А пробовали… » — Может это честно, но это не продакшн решение на мой вкус. После ребута всей этой конструкции вы получите фарш в данных. Но если у вас есть успешный опыт такошо применения MySQL и у вас не было коррапта данных, то я снимаю перед вами шляпу.
4. «Почему не взять сразу ее?» — потому что она ни разу не in-memory, сильно медленнее.
Его 3 раза об этом спрашивали, но он так толком и не ответил… Видимо, в их кейсе не учитывается остывание данных.
Вот что говорит официальный форум 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.
По поводу дороже, вы имеете ввиду стоимость лицензии или железа?
В том смысле, что берем кэш, прикручиваем к нему фичи БД, выкидываем девяносто процентов данных в другую «медленную» базу, и он показывает чудеса производительности в качестве БД. И не понятно, толи выигрыш за счёт замечательной архитектуры, толи за счёт выигрыша по объему. Правда используют хранение данных в памяти, а не на диске, что может дать выигрыш в скорости.
И как отметили, интересно было бы почитать, как происходит разбивка данных на горячие и холодные.
Разбивка пока происходит руками. В целом, это не сложно. Работаем над автоматическим решением. Если хотите, можем в личке пообщаться anikin@corp.mail.ru — посоветую вам как можно в ваших кейсах разбить горячие и холодные данные.
Дайте, пожалуйста, ссылку на исходники базы данных, которая
а) работает быстрее Тарантула и/или имеет лучший memory footprint (со ссылками на бенчи, с открытым исходным кодом бенчей, с инструкцией как запустить, с инструкцией как теструемые системы установить и настроить)
б) аналогична Тарантула по функционалу
И, если а) и б) окажутся правдой + для выяснения этой правды мне хватит день моего времени, то я бы с удовольствием взял бы вас на работу на огромную зарплату и перевел бы все в Почте@Mail.Ru/Облаке@Mail.Ru с Tarantool на вашу новую базу данных.
«Я не занимаюсь базами данных с 95 года» — наша команда, вся до одного, начала заниматься базами данных уже после 95 года. Видимо, поэтому они не используют best practices от <95 года. Но мы ребята открытые, готовы учиться всему новому, в т.ч. хорошо забытому старому.
«Если захочу, то Вы возьмете меня безо всяких предварительных условий:)))» — разумеется. Будем ждать, пока вы захотите.
Тут, в принципе, на слайде все написано – наш путь, через который мы прошли, но факт в том, что для большинства задач были достаточны 2 инстанса всего Tarantool – один мастер, второй – реплика, потому что нагрузка, которая идет на одну из баз данных, на один инстанс, она, скорее всего, обеспечит всю вашу полосу нагрузки, которая шла раньше на весь ваш кластер SQL серверов.
Не совсем понял это утверждение, ведь у тарантула инстансы не вертикально масштабируемые. В соседнем посте Костя Осипов пишет:
Мы, все равно, говорим, что будем шардировать данные, т.е. у нас горизонтальное масштабирование – это норма, поэтому мы даже не пытаемся сделать так, чтобы база данных работала эффективно на одной машине.
Т.е. у него идёт совсем другой посыл – вы всё равно вырастите настолько, что вам нужен будет шардинг, поэтому даже чтобы загрузить свой 32-ядерный сервер, поставьте туда несколько инстансов тарантула.
Tarantool: как сэкономить миллион долларов на базе данных на высоконагруженном проекте