О как, человек с зарегистрированным всего неделю назад аккаунтом и всего одним комментарием уже где-то что-то говорил — что-то крайне смахивающее на джинсу...
> Вот можете прям в деталях пояснить как бы вы его написали?
Сходу нет, но с mysql и redis это не выглядит как совсем уж космическая задача. А вот поинт насчет скорости записи выглядит существенный. В обычную базу, действительно, очень быстро писать не выйдет.
Проблема №1 решается т.н. двухфазным коммитом: мы либо пишем и в базу и в кеш, либо никуда не пишем, а читаем потом только из кэша. Моргание сети и прочее тут не является принципиальной проблемой, т.к. это всё устранимо (в конце концов, когда-то и электричество может «моргнуть», и без репликации по разным стойкам/дц тут ничего не поделаешь).
Далее, имея двухфазный коммит для пары кэш+бд, используем персистентный кэш с включённым LRU — например тот же Redis. На выходе получаем и гарантированную запись, и быстрые чтения, и быстрый холодный старт, и как бонус — автоматическое, а не ручное разделение горячих и холодных данных, используя при этом стандартные проверенные решения — что является большим плюсом, перевешивающим заморочки с малоизвестным, пусть и навороченным софтом (я это говорю со стороны, как внешний наблюдатель — всё-таки популярность и удобство Redis'а — это тоже немаловажный фактор на фоне десятка-другого процентов скорости).
В итоге имеем решение аналогичное предложенному, плюс сокращаем работу по ручному отделению горячих данных от холодных, плюс ещё экономим память на горячих данных (у вас ведь всё лежит в памяти, несмотря на то что горячих данных там от силы половина, а то и меньше). И экономим тот же самый миллион долларов.
>>> В качестве бонуса пользователь получает все остальные наши возможности — мастер-мастер репликацию и подключаемые движки хранения, например.
Года два назад я слышал на каком-то докладе про то, что в тарантуле уже есть дисковый движок. Но по отзывам тех кто его пробовал — работа с ним была нестабильной и его использование в продакшене из-за этого было немного стремновато. Как сейчас с ним обстоят дела? Он уже стабилен и зарелизен или пока еще нет?
И еще вопрос про репликацию: мастер-мастер репликация — достаточно сложная, но нужная фича для отказоустойчивой работы системы. Правильно ли я понимаю, что тарантул умеет синхронно реплицировать данные между узлами, и в случае выхода из строя скажем одного из трех узлов продолжать работу и писать данные на оставшиеся два, и данные при этом остаются всегда консистентными?
У меня есть там знакомые просто, могу уточнить как-нибудь, если это не NDA тайна. Я и не говорил, что заморозили из-за эллиптикса, я лишь сказал что и эллиптикс не подошёл как инструмент. Возможно, вы спросили кого-то, кто там уже не работает, потому что сейчас, насколько я знаю, в той почте эллиптикса уже точно нет.
Полностью согласен, каждый инструмент имеет свои особенности.
Насчёт яндекса я подробнее не знаю что там за история с kiwi, вроде это тоже система хранения аналогичная.
Про рамблер знаю чуть более подробно — почта и эллиптикс не взлетели совершенно независимо друг от друга. В итоге хранение решили взять другое. А у аватарницы тоже были проблемы с эллиптиксом, поэтому тоже не пошло.
Примеры в основном из «классических» компаний — в мейлру посмотрели эллиптикс и решили написать своё, в рамблере тоже попробовали и отказались — в качестве альтернатив выбор был между ceph или Riak, в яндексе вроде даже тоже от эллиптикса кое-где отказались (слышал про уход на hbase, уход на «самописную» систему kiwi).
Про 2GIS вот не знал, кстати.
Насколько мне известно, эта информация не совсем верна.
Rambler полностью отказался от использования Elliptics'а.
Mail.Ru только посмотрел, но решил в итоге держаться от него в стороне и использовать свои наработки.
Яндекс — некоторые проекты пожалели, что связались этой системой хранения (по причине наличия многих неочевидных нюансов), но кто-то уже уйти от неё не может, а кто-то даже сумел выпилить Elliptics.
Не имею ничего против Elliptics, но проблем с ней по отзывам немало.
Имелось в виду — в оригинале на самом деле чёрно-белая, но с промежуточными оттенками серого (8 бит ч/б цвет), а тут 1 бит на цвет — строго чёрный или белый, без плавных переходов.
Посмотрел на dovecot — там вроде бы вполне прозрачная система плагинов для хранилищ. Неужели настолько плохо совместимыми оказались его API и API хранилища — настолько, что написать с нуля сервер оказалось дешевле? Или, как ответили выше, процессорное время тоже стало узким местом (или ещё что-то)?
Спасибо за статью! А можно вкратце про dovecot — помимо сложностей с прикручиванием к хранилищу, какие ещё с ним были проблемы? От него пришлось отказаться в основном из-за хранилища, или это была только половина проблемы?
Отличная работа, очень качественно сделано. Ни в коем случае не останавливайтесь на достигнутом! Помните, что связка программист + дизайнер практически неубиваема и ничем не контрится! ;)
Сходу нет, но с mysql и redis это не выглядит как совсем уж космическая задача. А вот поинт насчет скорости записи выглядит существенный. В обычную базу, действительно, очень быстро писать не выйдет.
Далее, имея двухфазный коммит для пары кэш+бд, используем персистентный кэш с включённым LRU — например тот же Redis. На выходе получаем и гарантированную запись, и быстрые чтения, и быстрый холодный старт, и как бонус — автоматическое, а не ручное разделение горячих и холодных данных, используя при этом стандартные проверенные решения — что является большим плюсом, перевешивающим заморочки с малоизвестным, пусть и навороченным софтом (я это говорю со стороны, как внешний наблюдатель — всё-таки популярность и удобство Redis'а — это тоже немаловажный фактор на фоне десятка-другого процентов скорости).
В итоге имеем решение аналогичное предложенному, плюс сокращаем работу по ручному отделению горячих данных от холодных, плюс ещё экономим память на горячих данных (у вас ведь всё лежит в памяти, несмотря на то что горячих данных там от силы половина, а то и меньше). И экономим тот же самый миллион долларов.
Если я не прав — ЧЯДНТ?
Года два назад я слышал на каком-то докладе про то, что в тарантуле уже есть дисковый движок. Но по отзывам тех кто его пробовал — работа с ним была нестабильной и его использование в продакшене из-за этого было немного стремновато. Как сейчас с ним обстоят дела? Он уже стабилен и зарелизен или пока еще нет?
И еще вопрос про репликацию: мастер-мастер репликация — достаточно сложная, но нужная фича для отказоустойчивой работы системы. Правильно ли я понимаю, что тарантул умеет синхронно реплицировать данные между узлами, и в случае выхода из строя скажем одного из трех узлов продолжать работу и писать данные на оставшиеся два, и данные при этом остаются всегда консистентными?
Насчёт яндекса я подробнее не знаю что там за история с kiwi, вроде это тоже система хранения аналогичная.
Про рамблер знаю чуть более подробно — почта и эллиптикс не взлетели совершенно независимо друг от друга. В итоге хранение решили взять другое. А у аватарницы тоже были проблемы с эллиптиксом, поэтому тоже не пошло.
Про 2GIS вот не знал, кстати.
Rambler полностью отказался от использования Elliptics'а.
Mail.Ru только посмотрел, но решил в итоге держаться от него в стороне и использовать свои наработки.
Яндекс — некоторые проекты пожалели, что связались этой системой хранения (по причине наличия многих неочевидных нюансов), но кто-то уже уйти от неё не может, а кто-то даже сумел выпилить Elliptics.
Не имею ничего против Elliptics, но проблем с ней по отзывам немало.
Должна успешно открываться на 32х и 64х битных системах.