company_banner

Под высокой нагрузкой: наши способы применения Tarantool



    Многие из вас уже слышали о нашем проекте Tarantool. Это СУБД, или, попросту говоря, база данных с сервером приложений внутри. Tarantool — проект с открытым исходным кодом, и с ним может работать кто угодно. Развивается этот проект уже больше восьми лет. В Mail.Ru Group Tarantool активно используется более чем в половине продуктов: в Почте, Облаке, Моём Мире, Агенте и др. Все сделанные нами доработки этой БД мы коммитим обратно на GitHub, и сообществу доступна та же самая версия БД, что и нам. Сейчас у нас есть клиентские библиотеки почти ко всем языкам, мы сильно прибавили в этом направлении за последний год. Часть из них написана сообществом, часть — нами. Если появляется какая-то более эффективная библиотека, то мы просто делаем её официальной. Мы стараемся, чтобы всё было прямо из коробки — и БД, и библиотеки.

    Одна из главных особенностей Tarantool заключается в объединении свойств БД и кэша. БД — это нечто надёжное, с транзакциями, серверным языком запросов. А кэш быстрый. И оба этих мира органично сливаются воедино в Tarantool. Эта БД предназначена для использования в высоконагруженных проектах и для работы с горячими данными.

    Сравнение с классическими решениями


    Если вы работаете с «традиционными» БД, например MySQL или Oracle, то наверняка сталкивались с тем, что вашей системе не хватает свойств кэша: большого быстродействия, маленького Latency и многого другого. В традиционных БД всего этого нет. У кэшей тоже есть свои недостатки, в том числе отсутствие транзакций. Даже если вы используете кэш + БД, например MySQL в связке с Memcached или PostgreSQL в связке с Redis, то это всё равно приводит к компромиссам: у вас частично теряются свойства БД, к примеру отсутствуют транзакции, хранимки, вторичные индексы. Также утрачиваются какие-то свойства кэша, например большая пропускная способность на запись. При этом появляются новые проблемы, самые серьёзные из которых — несогласованность данных и холодный старт.

    Но если этот компромисс вас не устраивает и вам нужны все преимущества кэша и БД, то обратите внимание на Tarantool. Он лишён всех перечисленных недостатков. Tarantool устроен очень просто. Грубо говоря, он хранит на диске два файла: снапшот данных на какой-то момент времени и лог всех транзакций начиная с этого момента времени. Мы проводили тестирование на скорость холодного старта. Чтение файлов в память с магнитного диска происходит со скоростью 100 Мб/с. То есть, например, база данных в 100 Гб считается за 1000 с — примерно 15 мин.

    Для сравнения, когда мы игрались с MySQL и PostgreSQL, там всё было гораздо хуже. Они хранят данные на диске. Там нет такой проблемы, что база не отвечает, пока всё не загрузит в память. Но кэш у них прогревается гораздо медленнее (1–2 Мб/с), и поэтому нужно прибегать к разным трюкам, наподобие предварительного прогрева индекса. Те, кто админит MySQL, это прекрасно знают. Tarantool же просто встаёт и работает. Время холодного старта — минимально возможное.

    Недостатки


    Тем не менее нас не всё удовлетворяет в этой БД. Первое, над чем мы работаем, — это дисковое хранилище. Tarantool изначально создавался как In-Memory БД. Благодаря своей скорости и низкой потребности в серверах, по стоимости владения он всё равно лучше, чем традиционные дисковые БД. Но поскольку Tarantool — это In-Memory БД, то возникает вопрос: что делать с холодными данными? С горячими данными он работает эффективно, но всё лежит в памяти, в том числе и холодные данные. Поэтому мы разрабатываем дисковое хранилище. Кстати, у нас в продакшене все Tarantool’ы работают на самых дешевых SATA-дисках. SSD можно поставить только для быстрого старта, но при наличии реплик это неактуально.

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

    Также мы разрабатываем автоматические кластерные решения. У нас сейчас их несколько, но они не универсальные. А мы хотим сделать одно правильное универсальное, чтобы можно было поставить Tarantool на десять серверов, а внутри всё шардилось, решардилось, реплицировалось, и чтобы голова не болела.

    Кроме того, мы делаем поддержку разных систем, например SQL. Опять же, она пока в нестабильном состоянии, но мы возлагаем большие надежды. Поддержка SQL нужна в основном для того, чтобы можно было легко мигрировать. В той же Почте Mail.Ru есть под сотню MySQL-серверов, чью нагрузку можно перенести на пару Tarantool’ов. Но поскольку нет поддержки SQL, то нужно переписывать тонну кода. Так что проще один раз сделать поддержку.

    У нас используется свой собственный аллокатор, типа Slab-аллокатора, позволяющий минимизировать влияние фрагментации памяти. Но он всё ещё неидеален, мы постоянно работаем над его улучшением.

    Как подсчитать объём памяти для Tarantool’а


    У Tarantool’а очень хороший Memory Footprint, а это означает маленький overhead на хранение данных. Размер данных на диске (или в памяти) лишь немногим больше размера чистых данных. Если вам нужно хранить 1 млрд строк, в каждой из которых десять полей, размер поля — четыре байта, то это будет 4 х 10 х 1 млрд плюс 1–10% оверхеда на управляющие структуры.

    Наши юзкейсы


    В Mail.Ru Group Tarantool используется для решения самых разных задач — суммарно наберётся несколько сотен инсталляций этой БД, из них три самые высоконагруженные: система аутентификации, система push-уведомлений и система показа рекламы. Расскажу подробнее про каждую из них.

    Система аутентификации



    Система аутентификации по логину и паролю


    Система аутентификации по сессии/токену

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

    • Востребованность. Каждая страничка, каждый Ajax-запрос, каждый вызов мобильного API обращается к этой системе, чтобы аутентифицироваться.
    • Низкое время отклика. Пользователи не любят ждать, они хотят быстро получать всю информацию. То есть каждый вызов должен быстро обрабатываться.
    • Высокая доступность. Система аутентификации не должна быть причиной ошибки 500. Если она не может обслужить запрос, то пользователь не обслуживается вообще, ведь дальше не идёт весь поток исполнения серверного запроса.
    • Постоянные обращения к хранилищу. Каждый хит системы авторизации — это проверка сессии или логина-пароля, т. е. некий Select в базе, а иногда даже Update. Ещё есть системы anti-bruteforce и anti-fraud — нужно проверять на каждый хит, с хорошими ли намерениями обращается пользователь. Каждый хит системы авторизации может что-то обновлять, например последнее время сессии. Если это авторизация по логину и паролю, то нужно создать сессию, а значит, сделать Insert в базу. При anti-bruteforce-проверке нужно записать месторасположение пользователя (IP-адрес или что-то ещё). То есть процессов чтения и записи немало. Систему авторизации постоянно пытаются взломать, что создаёт дополнительную нагрузку, ведь она каждый раз обращается к БД, чтобы потом отказать злоумышленнику в авторизации.
    • Большой объём данных. В этой системе должна быть информация обо всех пользователях.
    • Данные должны быстро экспайриться. По сути, это тоже апдейты. Например, должны экспайриться сессии пользователя.
    • Персистентность. Всё должно быть сохранено на диске, каждое изменение. Cессии пользователей нельзя хранить в Memcached, потому что вы их потеряете при падении сервера, и пользователям придётся заново вводить логин и пароль. А они не любят этого делать.

    Некоторые из этих требований удовлетворяются, только если вы используете кэш. Например, высокая нагрузка, экспирации и прочие вещи, которые характерны для кэша. Другие требования удовлетворяются, только если вы используете базу данных. Поэтому система должна быть основана и на кэше, и на БД, объединённых в одно решение. Она должна быть надёжной и долговечной, как грузовик, но при этом быстрой, как спортивная машина.

    Сейчас нагрузка по проверке логинов-паролей на нашу систему аутентификации составляет примерно 50 тыс. запросов в секунду. Кажется, что не так много, но по каждому запросу нужно сделать массу работы, в том числе проверить anti-bruteforce, выполнить много транзакций в БД и т. д. Tarantool со всем этим успешно справляется.

    Зато количество аутентификаций по сессии достигает 1 млн в секунду. Это то, что приходит со всего портала. Эту нагрузку держат всего 12 серверов: четыре с сессиями и восемь с профилями пользователей. При этом они загружены всего на 15–20%, т. е. запас прочности очень велик. Просто мы любим обычно перезакладываться.

    Система push-уведомлений




    Сейчас всё больше и больше пользователей переходят в мобильный сегмент. Они в основном используют там приложения, а не обычный мобильный веб. И в приложениях есть такая штука, как push-уведомления. Когда на стороне сервера происходит какое-то событие и нужно уведомить об этом мобильное устройство, то как обычно это устроено? Самому мобильному приложению нет нужды держать соединение с сервером, это происходит на уровне операционной системы, которая соединяется с соответствующим веб-гейтом и периодически проверяет наличие push-уведомлений. То есть серверный код ходит в специальный API от iOS и Android, которые уже сами связываются с операционными системами на мобильных устройствах.

    Чтобы соединиться с этими API и отправить данные, требуется как-то идентифицировать пользователя, поэтому пересылается токен. Токен надо где-то хранить. Более того, на одного пользователя нужно несколько токенов, потому что у него может быть несколько устройств. И пересылать токен нужно на каждое событие на сервере, о котором вы хотите уведомить пользователя. А таких событий много. Чем чаще вы уведомляете пользователя, тем чаще он пользуется вашим приложением. Поэтому для системы push-уведомлений нужна быстрая и надёжная БД.

    Мы воспользовались Tarantool’ом просто потому, что у нас огромное число запросов и транзакций, для отправки push’а нужно сделать множество проверок. Причём сделать быстро. Мы не можем тормозить в этом месте, ведь это Server Side, от работы которого зависит много процессов, потребляющих много памяти.

    Как вы думаете, хорошо ли, если Server Side напрямую соединяется с Android или iOS? Это плохо по нескольким причинам. Во-первых, с точки зрения архитектуры — потому что вы теряете универсальность. Ведь может появиться Windows Mobile или ещё кто-нибудь, вырастет сложность разработки, потребуется доработать кучу систем. Во-вторых, у вас возникает дополнительная точка отказа, и всё взаимодействие значительно усложняется. И в-третьих, эти мобильные API могут тормозить или упасть. Они не гарантируют быстрый ответ, могут отвечать несколько секунд. Поэтому нужна какая-то прослойка, очередь, куда помещаются все изменения, а оттуда они улетают на Apple и Google, в их API. Терять эти уведомления мы не можем. Так что очередь должна всё хранить на диске, но при этом быть очень быстрой. Tarantool полностью удовлетворяет этим критериям. Наша система выдерживает достаточно большую нагрузку — 200 тыс. запросов в секунду, и запись, и чтение. Каждое обращение в очередь — это запись, транзакция, которая реплицируется на несколько реплик. Тем не менее всё работает очень быстро.

    Система показа рекламы




    У нас большой портал, и мы показываем пользователю рекламу почти на каждой странице. Управляет этим процессом система показа рекламы, которая называется Target. Одна из основных проблем рекламной системы — она должна работать супербыстро и держать супербольшую нагрузку. Даже больше, чем система аутентификации. Потому что сессии — это обращение к БД, может быть несколько обращений на каждый вызов.

    Реклама показывается не только на наших страницах, но и на страницах партнёров, и это тоже очень большая нагрузка. Допустим, на странице десяток рекламных блоков. Для каждого из них нужно сходить в источники данных с информацией о профиле пользователя, агрегировать результат, определить, какую именно рекламу показать, отобразить её. И всё это сделать быстро (норматив сейчас — 50 мс), потому что пользователи не любят ждать. К тому же реклама не несёт никакой функциональности для пользователя, и она точно не может служить оправданием медленной работы сервисов.

    Наша система показа рекламы — один из самых больших и высоконагруженных кластеров Tarantool в мире: суммарно каждую секунду осуществляется 3 млн операций и около 1 млн транзакций (апдейтов).

    В заключение


    Tarantool рождён для высокой нагрузки. Если же нагрузка у вас невысока, то он обеспечит хорошее время ответа — одна миллисекунда или меньше. Традиционные БД даже на маленькой нагрузке не умеют выдавать ответ с такой скоростью. А часто нужно сделать несколько обращений, все эти миллисекунды складываются, и получается достаточно печально. Tarantool обеспечит вам высокий RPS, низкое Latency, высокий Uptime, поможет выжать все соки из железа, какие только можно, и при этом у вас будет БД с транзакциями, репликациями и серверными процедурами.
    Mail.ru Group
    1145.69
    Строим Интернет
    Share post

    Similar posts

    Comments 38

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

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



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

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

        >БД — это нечто надёжное, с транзакциями, серверным языком запросов.
        А как с «серверным языком запросов у 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.
          +6
          Спасибо за ваш детальный коментарий! Отвечаю и комментирую по порядку сверху вниз.

          1. Все можно полностью написать на Lua на стороне сервера в хранимой процедуре. И зачастую многие кейсы написать на Lua проще чем на SQL и код выглядит понятней. SQL, если вы намекаете на него, пока нет. В процессе разработки.
          2. При большом количестве индексов и большом количестве данных, да, будет так как вы сказали. Однако в случае MySQL холодный старт в подобных кейсах на наших нагрузках в разы дольше. Т.е. тут смотря что с чем сравнивать. Однако, если на ваших ворклоудах MySQL или любая другая база холодно стартует быстрее Тарантула, то интересно было бы послушать. Заранее спасибо за описание вашего кейса! :)
          3. "Что произойдет, если я сделаю «select *» из огромной базы..." — оверхед будет зависеть от размера туплов. Копия базы хранится в памяти не будет, если вы, конечно, намерено не создадите временный спейс и не скопируете туда все целиком.
          4. "Упаковка tuple-ов, выбранных из тарантула..." — можете показать пример кода, чтобы было чуточку понятней?
          5. Попробуйте 1.6.8. Там очень много доработок в аллокаторе.
          6. Индексы тоже потребляют память. Однако по нашим исследованием, сильно меньше чем у всех остальных конкурентов. Если у вас есть обратные данные, то интересно было бы их изучить. Заранее спасибо!
          7. "И коль скоро речь зашла об индексах, есть ли… " — Есть. Могу связать вас с разработчиками, они расскажут детали.
          8. "Есть какие-то планы на использование многоядерности ..." — в планах есть. Но по нашему опыту и опыту многих наших кастомеров узкое место не ЦПУ. Т.е. даже если на сервер пихать по 256Gb памяти не создается на него такая нагрузка в реальных случаях, чтобы CPU не справлялся. Опять же, если у вас есть реальный кейс, когда это не так, то очень просим показать его нам. Мы его препарируем и все ускорим, обещаю! :)
          9. Мы работаем сейчас над миграцией.
            +3
            >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, я был бы весьма недоволен таким ходом вещей.
              +2
              • 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 будет абсолютно другой принималось после очень бурной дискуссии внутри. Но от этого никуда не деться. Лучше иногда сразу решить архитектурные проблемы, чем таскать вечно легаси. И это надо было делать на старте проекта, чем раньше тем лучше. Т.е. я хочу сказать, что мы вполне себе осознаем, что это вызвало недовольство клиентов, потому что мы сами клиенты Тарантула. В любом случае, мы признательны вам за ваш фидбек, он помогает нам стать лучше!
          0
          Спасибо за ваши публикации, очень интересно читать!
          Мне кажется, что в базе не главное как она быстро разогревает кеш, а скорость операций, латенси и т.д.
          Какой синтаксис у ваше БД?
          0
          Скажите, пожалуйста, не пробовали ли вы использовать tarantool для хранения логов и поиска по ним?
            0
            О, это отличный вопрос! У Тарантула есть дисковый движок Sophia, который как раз заточен под такую нагрузку — сумасшедшее количество записей и мало чтений. Попробуйте и поделитесь опытом. А мы готовы ответить на все ваши вопросы, которые возникнут в процессе.
              0
              Ясно, спасибо, а куда направлять вопросы?
                +2
                Самый простой способ — это прямо на stackoverflow.com.
                Я записал небольшую видеоинструкцию как это сделать https://cloud.mail.ru/public/5Zdc/My1gTRp2F
                Мы мониторим все вопросы там с тегом Tarantool и отвечаем.
                Другой более традиционный способ — это написать на support@tarantool.org
                0
                На прошлогоднем highload++ говорили, что Sophia подходит под логи, но не применима под реально долгое хранение большого объема (сотни терабайт). На какой максимальный объем данных её стоит её рассматривать, относительно кейса с логами?
                Если правильно понимаю, при большом объеме вариант или гибридный (память+диск) либо только хранение на диске.
                Стоит ли её вообще рассматривать в таком кейсе: постоянное добавление данных, но при этом достаточно ресурсоемкие выборки большого количества (2-5+ млн.) объектов.
                  0
                  Мы как раз прямо сейчас внедряем Sophia для полнотекстового поиска в Почте Mail.Ru. Там 3 петабайта данных. Поиски относительно редки, но они могут перебирать много информации. При этом наполнение индекса идет постоянно и под высочайшими нагрузками. Т.е. кейс с логами очень похож и Sophia должна тянуть. Этот движок мы пока считаем экспериментальным и он у нас в состоянии test-bug-fix. Но при этом мы на него имеем большие планы по развитию, и поэтому я так открыто и явно говорю про кейс с поиском по Почте.
                    0
                    Спасибо за ответ, да, масштабно! Было бы интересно почитать про технические моменты такого решения, если сможете хотя бы частично приоткрыть детали? Вообще, поскольку это key-value, то решение наверняка очень низкоуровневое, вплоть до создания групп ключей под разные нужды, организация кластера и отказоустойчивость, отдельная проблема параллельные поиски и вставки (наверное для embed решения это тоже не очень тривиально)?
                    Еще вопрос, будете ли открывать какие-то сопутствующие технологии, появляющиеся при разработке кейса по почте (решения для кластера / полнотекстовый поиск / может быть сжатие)?
                      0
                      Мы в ближайшее время планируем выступить про это на конференции. Так что stay tuned! :) Раскрывать будем по максимуму все технологии, если они будут достаточно обобщенные, чтобы могли использоваться снаружи.
              0
              промахнулся
                0
                In Memory только пока?
                  +1
                  Есть два движка — in-memory и on-disk (называется Sophia). Sophia — это сильгно оптимизированный LevelDB. У него есть отдельный сайт: http://sophia.systems/
                    0
                    спасибо
                  0
                  Пол года назад начали тестировать Tarantool для внутренних проектов, потом выложили его как сервис на хостинге для своих клиентов. Но из-за отсутствия интеграции с CMS большим спросом он не пользовался. Я понимаю на текущий момент, он не совсем предназначается для рядовых пользователей, но планируется ли его использование/интеграция в популярные CMS?
                    0
                    Планируем, да. Но мы пока пытаемся собрать побольше фидбека. К примеру, если будет понятно, что та или иная популярная CMS поверх стандартной SQL-базы имеет какие-то запросы от пользователей, которые она не реализует, то мы сразу же ринемся туда.
                    В этой связи вопрос: можете в деталях описать, чем ваша текущая CMS поверх вашей текущей базы (MySQL, Postgres, Mongo и тд) вас не совсем устраивает?
                      0
                      Думаю это больше вопрос к разработчикам CMS и систем кеширования для них. Задам его web студиям с которыми сотрудничаем.
                      0
                      Так вы его как выложили то как хранилище для данных? В таком виде оно врятли чем то лучше redis.
                      т.е. для CMS от Tarantool будет не много проку. нужно приложение (или CMS) писать полностью на Tarantool/Lua это у вас возможно?
                        +1
                        Написать, возможно, конечно.
                          0
                          да, пользователям предоставляется все возможности tarantool, фактически запускается отдельная копия в docker контейнере Если его можно было бы использовать как прозрачную замену redis/memcache, даже без дополнительных возможностей, количество людей которые захотели бы его протестировать возросло. Целесообразность такого использования, как Вы заметили — уже другой вопрос.
                            +1
                            В Тарантуле поддержан memcached-протокол. Как минимум прозрачную замену memcached он обеспечивает. В Mail.Ru у нас почти все memcached — это на самом деле Тарантулы, ибо это по скорости быстрее, но при этом есть persistence и репликация. Насчет Redis-протокола — он есть в планах.
                        –2
                        Я же говорил, что Tarantool это мейнстрим сейчас
                          +4
                          О как, человек с зарегистрированным всего неделю назад аккаунтом и всего одним комментарием уже где-то что-то говорил — что-то крайне смахивающее на джинсу...
                          +2
                          danikin хотелось бы windows-версию. +1 к набиранию "критической массы" для виндоус-версии :-)
                            0
                            Олег, записал ваше пожелание. Спасибо! :)
                            0
                            Нужен ли дополнительный кэш APC/APCu, или Tarantool его заменит? Интересно бы увидеть бенчмарк.
                              +1
                              Не нужен. Везде, где мы используем Тарантул, по моим сведениямм мы ничего на веб-серверах не кэшируем. Общие бенчмарки есть: http://sh5.tarantool.org/. Но конкретно с APC/APCu не сравнивали, но мысль интересная :) В любом случае <1ms на запрос и 100K-1600K запросов на ядро (зависит от сложности запросов и от оптимальности их отправки из клиента) должно хватить почти на все кейсы (и реально хватает даже на наши мейлрушные гигантские нагрузки).
                                0
                                • промахнулся -
                                0
                                По сравнению с локальным memcached (та же машина) apc дает очень ощутимое ускорение. Так что лучше "побенчмаркать" свой случай.

                              Only users with full accounts can post comments. Log in, please.