Как стать автором
Обновить

Комментарии 38

Скажите, а есть у вас планы поддерживать Windows? Я заходил на страницу проекта и там данная платформа в списке отстутствует…
Буду очень признателен за ответ!
Пока в планах нет. Набираем критическую массу желающих :) Можете рассказать подробней про ваш кейс? Почему именно Windows?
Обильное количество статей по Tarantool в последнее время, меня тоже заинтересовало попробовать на реальном кейсе в действии данную СУБД. Все что меня ограничивает — отсутствие поддержки Windows, поэтому хотел поинтересоваться сколько должно набраться критической массы… чтобы Вы поддержали работу на Windows платформе?

Относительно проекта, где я хотел бы попробовать Tarantool — это бесплатный сервис для форматирования SQL запросов. При каждом клике отправляется статистика какие настройки изменились и далее по этим данным делается аналитика:



Что чаще всего меняется… Tarantool-у такое по силам? :)
Вполне по силам! :) А почему именно под Windows? Linux-хостинг же всяко дешевле за одно и то же железо.
А почему именно под Windows?

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

>БД — это нечто надёжное, с транзакциями, серверным языком запросов.
А как с «серверным языком запросов у tarantool»? Все еще нужно писать join-ы руками? Что делать, когда есть необходимость выбрать значительную часть dataset-а по нетривиальному условию? Писать server-side lua программу плюс клиентское приложения под последовательный вызов этой серверной функции?

>Чтение файлов в память с магнитного диска происходит со скоростью 100 Мб/с. То есть, например, база данных в 100 Гб считается за 1000 с — примерно 15 мин.
Правда время простоя будет существенно больше, потому что данные надо не только прочитать с диска, но и перестроить индексы. Иногда — много индексов. Будьте готовы к «холодному старту» за полчаса минимум. И если что-то произойдет и с репликой — добро пожаловать в получасовой downtime.

И, раз уж вы говорите о больших объемах данных, можете ответить на пару вопросов:
1) Что произойдет, если я сделаю «select *» из огромной базы? От чего будет зависеть дополнительный оверхед по памяти? От размера tuple-ов или от их количества? В какой момент эта дополнительная память будет освобождена: после полного вычитывания запроса клиентом или «по мере отправки»?
2) Упаковка tuple-ов, выбранных из тарантула, в lua-шную таблицу делает дубликаты этих tuples?

>У нас используется свой собственный аллокатор, типа Slab-аллокатора, позволяющий минимизировать влияние фрагментации памяти.
Позвольте спросить, каким образом? Без переноса данных между slab-ами одного класса, при определенных паттернах нагрузки возникает забавная ситуация, когда heap состоит из огромного количества полупустых slab-ов «мелких» объектов, а на выделение более крупного объекта памяти уже не хватает. К сожалению, сталкивался лично в 1.5 при «разрастании» tuple-ов. «Лечил» рестартом.

>Если вам нужно хранить 1 млрд строк, в каждой из которых десять полей, размер поля — четыре байта, то это будет 4 х 10 х 1 млрд плюс 1–10% оверхеда на управляющие структуры.
Простите, но как же вторичные индексы? Мне вот, например, не хочется выяснять из кода, дублируются ли значения ключевых полей в индексы, или используется указатель на поле в tuple-е? Между прочим, очень животрепещущий вопрос, когда ключ занимает «значительную часть» tuple.

И коль скоро речь зашла об индексах, есть ли способ обойти space с HASH-индексом по primary key в условиях изменения space-а? В РСУБД даже в таком случае «select *» предсказуемо себя ведет.

Есть какие-то планы на использование многоядерности при обработке немодифицирующих запросов? При использовании «lua-join-ов» задекларированные «сотни тысяч запросов в секунду» очень быстро превращаются в «пару десятков тысяч», причем узким местом становится именно CPU, а не RAM, так что шардинг в таких условиях видится костылем, а не панацеей.

Я правильно понимаю, что версия 1.5 теперь abandoned и миграция данных 1.5 => 1.6+ — моя головная боль? Запрос «tarantool migration guide» выводит на репозиторий сотрудника Mail.Ru с, кхм, не совсем очевидной инструкцией. Есть ли какие-то гарантии (понимаю, в контексте бесплатного open source продукта это звучит неуместно, но все же), что эта история не повторится в ближайшее время, когда в текущем формате сериализации обнаружится «фатальный недостаток»? Почему просто нельзя сделать в 1.6 reader снапшотов и xlog в формате 1.5? Набор примитивный операций из 1.5 навряд ли был «урезан» в 1.6.
Спасибо за ваш детальный коментарий! Отвечаю и комментирую по порядку сверху вниз.

  1. Все можно полностью написать на Lua на стороне сервера в хранимой процедуре. И зачастую многие кейсы написать на Lua проще чем на SQL и код выглядит понятней. SQL, если вы намекаете на него, пока нет. В процессе разработки.
  2. При большом количестве индексов и большом количестве данных, да, будет так как вы сказали. Однако в случае MySQL холодный старт в подобных кейсах на наших нагрузках в разы дольше. Т.е. тут смотря что с чем сравнивать. Однако, если на ваших ворклоудах MySQL или любая другая база холодно стартует быстрее Тарантула, то интересно было бы послушать. Заранее спасибо за описание вашего кейса! :)
  3. "Что произойдет, если я сделаю «select *» из огромной базы..." — оверхед будет зависеть от размера туплов. Копия базы хранится в памяти не будет, если вы, конечно, намерено не создадите временный спейс и не скопируете туда все целиком.
  4. "Упаковка tuple-ов, выбранных из тарантула..." — можете показать пример кода, чтобы было чуточку понятней?
  5. Попробуйте 1.6.8. Там очень много доработок в аллокаторе.
  6. Индексы тоже потребляют память. Однако по нашим исследованием, сильно меньше чем у всех остальных конкурентов. Если у вас есть обратные данные, то интересно было бы их изучить. Заранее спасибо!
  7. "И коль скоро речь зашла об индексах, есть ли… " — Есть. Могу связать вас с разработчиками, они расскажут детали.
  8. "Есть какие-то планы на использование многоядерности ..." — в планах есть. Но по нашему опыту и опыту многих наших кастомеров узкое место не ЦПУ. Т.е. даже если на сервер пихать по 256Gb памяти не создается на него такая нагрузка в реальных случаях, чтобы CPU не справлялся. Опять же, если у вас есть реальный кейс, когда это не так, то очень просим показать его нам. Мы его препарируем и все ускорим, обещаю! :)
  9. Мы работаем сейчас над миграцией.
>1. И зачастую многие кейсы написать на Lua проще чем на SQL
SELECT… FROM a LEFT JOIN b on a.field = b.field ORDER BY… OFFSET x LIMIT y на SQL записывается очень просто. «DELETE FROM t WHERE secondary_nonuniq_key < y» или «UPDATE a SET field=field1+field2 WHERE non_uniq_key > x AND non_key_filed < y»— еще проще. Вы точно видели, _как_ это реализуется в тарантуле на lua? Приятного мало, очень много способов прострелить себе ногу.
Не понимаю, почему в штатной поставке нет проверенных и оптимизированных разработчиками функций для выполнения таких задач.

>3. оверхед будет зависеть от размера туплов. Копия базы хранится в памяти не будет
Не совсем вас понял: от размера или от количества? Потому что если от размера tuples, то это выглядит как копирование (или там copy-on-write — скопируются только tuples, которые были изменены во время отправки запроса?). Меня сильно смущает, что iproto-пакет содержит длину — возникает ощущение, что данные предварительно сериализуются и копируются во временный буфер.

>4. можете показать пример кода, чтобы было чуточку понятней?
http://pastebin.com/b4Y5u3CW

>5. Попробуйте 1.6.8. Там очень много доработок в аллокаторе.
Честно говоря, нет желания заниматься бенчмарками, потому что перехода на 1.6 не будет без процедуры миграции данных.

>6. 7.
Хотелось бы увидеть ответы на эти вопросы — они не требуют ни бенчмарков, ни исследований (при условии, конечно, что в проекте есть разработчики, которые хорошо знают его внутренности — не сочтите за грубость).

>8. Но по нашему опыту и опыту многих наших кастомеров
Я, конечно, не кастомер (то есть, не платил деньги за саппорт), но вот вам «реальный кейс» (кстати, надеюсь, вы насладитесь краткостью конструкции join): http://pastebin.com/tYttKMdZ
И прежде чем вы будете рекомендовать денормализацию, хочу заметить, что space0 => space1 и space1 => space2 — это many-to-one, причем «many» — это действительно много, и изменения в space2 должны быть сразу видимы в выборках.
Кстати, было бы круто, если бы вы на данном конкретном примере поделились, как можно обойти space1 по HASH-индексу в условиях изменения данных. По TREE я и сам умею.

>9. Мы работаем сейчас над миграцией.
Знаете, если бы я был вашим клиентом с tarantool 1.5, для которого выходят только багфиксы в течение последнего года и вы порекомендовали мне перейти на 1.6, я был бы весьма недоволен таким ходом вещей.
  • 1. Потому что SQL многогранен. Задачи у всех разные. Но идея написать какую-то общий туториал на эту тему — классная! Спасибо! Подумаем в эту сторону :)
  • 3. Каждый текущий тупл хранится в памяти. Все вместе в памяти не хранится, потому что оно не нужно.
  • 4. Теперь понял. Будет copy on write. Пока данные не меняются копия будет одна. Как только вы начнете менять или исходные данные или временную таблицу, сразу же случится копирование.
  • 6-7. Есть несколько вариантов связаться с разработчиками — написать на support@tarantool.org, завести тикет на github или написать в stackoverflow с тэгом Tarantool. Выбирайте любой из вариантов. Каждую проблему описывайте в отдельном тикете или в отдельном письме или в отдельном посте на stackoverflow. По каждой из проблем, соответственно, будет вестись дискуссия в отдельном треде. В любом случае, если ответы на будут вас удовлетворять, пишите на anikin@corp.mail.ru. Заранее спасибо!<li/>
    8. Т.е. в этом кейсе Тарантул уводит ядро ЦПУ в полку и перестает справляться с нагрузкой? (вроде, изначально речь шла о том, почему у нас нет мультеядерности). Насчет того как обойти space1, если вы не возражаете, давайте также откроем дискуссию с разработчикам, теми же средствами, что и в пп.6-7. Ок?

    9. Тут я могу только сказать, что Mail.Ru и я в том числе тоже являемся клиентами Тарантула, поэтому решение о том, что 1.6 будет абсолютно другой принималось после очень бурной дискуссии внутри. Но от этого никуда не деться. Лучше иногда сразу решить архитектурные проблемы, чем таскать вечно легаси. И это надо было делать на старте проекта, чем раньше тем лучше. Т.е. я хочу сказать, что мы вполне себе осознаем, что это вызвало недовольство клиентов, потому что мы сами клиенты Тарантула. В любом случае, мы признательны вам за ваш фидбек, он помогает нам стать лучше!
Спасибо за ваши публикации, очень интересно читать!
Мне кажется, что в базе не главное как она быстро разогревает кеш, а скорость операций, латенси и т.д.
Какой синтаксис у ваше БД?
Про скорость операций, вот тут бенчмарки Тарантула: http://sh5.tarantool.org/?first=1.6.8-580-ge79f3b9&last=1.6.8-585-g92a979b&tab=all
Вот тут сравнение с конкурентами: http://highscalability.com/blog/2015/12/30/how-to-choose-an-in-memory-nosql-solution-performance-measur.html
Синтаксис у языке запросов — Lua
Скажите, пожалуйста, не пробовали ли вы использовать tarantool для хранения логов и поиска по ним?
О, это отличный вопрос! У Тарантула есть дисковый движок Sophia, который как раз заточен под такую нагрузку — сумасшедшее количество записей и мало чтений. Попробуйте и поделитесь опытом. А мы готовы ответить на все ваши вопросы, которые возникнут в процессе.
Ясно, спасибо, а куда направлять вопросы?
Самый простой способ — это прямо на stackoverflow.com.
Я записал небольшую видеоинструкцию как это сделать https://cloud.mail.ru/public/5Zdc/My1gTRp2F
Мы мониторим все вопросы там с тегом Tarantool и отвечаем.
Другой более традиционный способ — это написать на support@tarantool.org
На прошлогоднем highload++ говорили, что Sophia подходит под логи, но не применима под реально долгое хранение большого объема (сотни терабайт). На какой максимальный объем данных её стоит её рассматривать, относительно кейса с логами?
Если правильно понимаю, при большом объеме вариант или гибридный (память+диск) либо только хранение на диске.
Стоит ли её вообще рассматривать в таком кейсе: постоянное добавление данных, но при этом достаточно ресурсоемкие выборки большого количества (2-5+ млн.) объектов.
Мы как раз прямо сейчас внедряем Sophia для полнотекстового поиска в Почте Mail.Ru. Там 3 петабайта данных. Поиски относительно редки, но они могут перебирать много информации. При этом наполнение индекса идет постоянно и под высочайшими нагрузками. Т.е. кейс с логами очень похож и Sophia должна тянуть. Этот движок мы пока считаем экспериментальным и он у нас в состоянии test-bug-fix. Но при этом мы на него имеем большие планы по развитию, и поэтому я так открыто и явно говорю про кейс с поиском по Почте.
Спасибо за ответ, да, масштабно! Было бы интересно почитать про технические моменты такого решения, если сможете хотя бы частично приоткрыть детали? Вообще, поскольку это key-value, то решение наверняка очень низкоуровневое, вплоть до создания групп ключей под разные нужды, организация кластера и отказоустойчивость, отдельная проблема параллельные поиски и вставки (наверное для embed решения это тоже не очень тривиально)?
Еще вопрос, будете ли открывать какие-то сопутствующие технологии, появляющиеся при разработке кейса по почте (решения для кластера / полнотекстовый поиск / может быть сжатие)?
Мы в ближайшее время планируем выступить про это на конференции. Так что stay tuned! :) Раскрывать будем по максимуму все технологии, если они будут достаточно обобщенные, чтобы могли использоваться снаружи.
In Memory только пока?
Есть два движка — in-memory и on-disk (называется Sophia). Sophia — это сильгно оптимизированный LevelDB. У него есть отдельный сайт: http://sophia.systems/
спасибо
Пол года назад начали тестировать Tarantool для внутренних проектов, потом выложили его как сервис на хостинге для своих клиентов. Но из-за отсутствия интеграции с CMS большим спросом он не пользовался. Я понимаю на текущий момент, он не совсем предназначается для рядовых пользователей, но планируется ли его использование/интеграция в популярные CMS?
Планируем, да. Но мы пока пытаемся собрать побольше фидбека. К примеру, если будет понятно, что та или иная популярная CMS поверх стандартной SQL-базы имеет какие-то запросы от пользователей, которые она не реализует, то мы сразу же ринемся туда.
В этой связи вопрос: можете в деталях описать, чем ваша текущая CMS поверх вашей текущей базы (MySQL, Postgres, Mongo и тд) вас не совсем устраивает?
Думаю это больше вопрос к разработчикам CMS и систем кеширования для них. Задам его web студиям с которыми сотрудничаем.
Так вы его как выложили то как хранилище для данных? В таком виде оно врятли чем то лучше redis.
т.е. для CMS от Tarantool будет не много проку. нужно приложение (или CMS) писать полностью на Tarantool/Lua это у вас возможно?
Написать, возможно, конечно.
да, пользователям предоставляется все возможности tarantool, фактически запускается отдельная копия в docker контейнере Если его можно было бы использовать как прозрачную замену redis/memcache, даже без дополнительных возможностей, количество людей которые захотели бы его протестировать возросло. Целесообразность такого использования, как Вы заметили — уже другой вопрос.
В Тарантуле поддержан memcached-протокол. Как минимум прозрачную замену memcached он обеспечивает. В Mail.Ru у нас почти все memcached — это на самом деле Тарантулы, ибо это по скорости быстрее, но при этом есть persistence и репликация. Насчет Redis-протокола — он есть в планах.
Я же говорил, что Tarantool это мейнстрим сейчас
О как, человек с зарегистрированным всего неделю назад аккаунтом и всего одним комментарием уже где-то что-то говорил — что-то крайне смахивающее на джинсу...
danikin хотелось бы windows-версию. +1 к набиранию "критической массы" для виндоус-версии :-)
Олег, записал ваше пожелание. Спасибо! :)
Нужен ли дополнительный кэш APC/APCu, или Tarantool его заменит? Интересно бы увидеть бенчмарк.
Не нужен. Везде, где мы используем Тарантул, по моим сведениямм мы ничего на веб-серверах не кэшируем. Общие бенчмарки есть: http://sh5.tarantool.org/. Но конкретно с APC/APCu не сравнивали, но мысль интересная :) В любом случае <1ms на запрос и 100K-1600K запросов на ядро (зависит от сложности запросов и от оптимальности их отправки из клиента) должно хватить почти на все кейсы (и реально хватает даже на наши мейлрушные гигантские нагрузки).
По сравнению с локальным memcached (та же машина) apc дает очень ощутимое ускорение. Так что лучше "побенчмаркать" свой случай.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий