Нет, так как мы не упираемся в скорость CPU — по большей части упоры в сеть, в диски, в подсистему менеджмента памяти linux. А диагностировать проблемы в java приложении значительно легче, чем в C. С этой позиции простой поиск github.com/scylladb/scylla/issues?utf8=✓&q=coredump дает некоторую пищу для размышлений.
Cерьезный прирост — это слишком обще. Интересно было бы узнать подробности что было до перехода на scylla и после? Что за данные? Насколько запросы к ним попадают в кеш? Да и общий профиль нагрузки. Не знаю, насколько это влезет все в коммент — может и на статью потянет ;-)
Не все ходят по JUGовским конференциям, части аудитории удобнее прочитать в виде статьи, а в свое время руки не дошли. Однако, что интересно, тема не потеряла актуальность за это время.
По итогам эксплуатации основная идея видно, что рабочая, за это время было множество мелких инцидентов, да и несколько крупных аварий, что позволило обнаружить и пофиксить множество проблем в основном в Cassandra — gossip (очень нехорошо ведет себя в нестабильной сети), repair, streaming, range tombstones, compaction, всего не упомнишь что потрогали или переписали.
Что, с одной стороны, может напугать, но с другой — подтверждает правильность того, что изначально выбирали движок для хранилища который мы знаем и можем сами поддерживать. Ведь проблемы есть абсолютно со всеми СУБД ( про синие экраны SQL Server рассказывал в лицах на Джокере, если помните ) весь вопрос в том кто и как быстро их может диагностировать и исправлять.
Естественно, если один из координаторов недоступен, то есть период когда невозможна запись транзакций. Тут все в полном соотвествии с CAP. Другое дело, что этот период очень короткий ( за счет отсутсвия выборов и присутсвия спекуляций ) — около 200-300мс, что позволяет повторить транзакцию с клиента при отказе координатора и при этом уложиться в таймаут. Что тоже не противоречит CAP, но на практике приводит к тому, что отказ координатора проходит незамеченным.
Оговорюсь, что это полностью разные системы, сравнивать их (совсем не) корректно. Можем попробовать сравнить разве что как реализован ACID там. Опять же мы не используем neo4j, поэтому мои выводы чисто теоретические и основаны на том, что я только что прочитал в neo4j.com/docs/operations-manual/current/ha-cluster/architecture
Итак:
1. Координатор транзакций и сторадж совмещен. Соотвественно, кратковременные тормоза в подсистеме ввода вывода приводят к тормозам на коммите. В c*one — координатор отделен от стораджа, стораджа составляют отдельный кворум со спекулятивным исполнением, что исключает подобный сценарий.
2. Запись попадает сначала на мастер и потом на все слейвы. Соотвественно если мастер сначала тормознул и потом выключился ( как это обычно и происходит ), то часть изменений будет пропущена, а при возврате такого мастера возникнет «Data branching», который «can be reviewed and the situation be resolved» — как я понимаю вручную. До этого времени, предположу, БД не работает как минимум на запись, а может и на чтение тоже. В c*one такая ситуация невозможна.
3. Выборы взамен отказавшего мастера происходят после обнаружения отказа протоколом raft. про что подробно написано в статье — в c*one выборы не запускаются.
4. Не нашел про партиционирование транзакций ни слова, предположу что мастер глобальный на все транзакции кластера. А как написано «If the master goes down, any running write transaction will be rolled back and new transactions will block or fail until a new master has become available.» означает что до завершения выборов запись данных полностью не работает. В c*one нет единого глобального мастера — их несколько, выборов нет, как уже писал.
5. А вот это намекает на проблемы в масштабировании «All instances in the cluster have full copies of the data in their local database files». Ну или это некорректно сформулировано.
В общем и целом, на основании доки, в neo4j достаточно классический подход к HA, он приблизительно такой же, как и в sql server например.
мы не используем mongodb, поэтому на основании практического опыта — нет. да и про то как работают их транзакции я не нашел статей — только маркетинговые материалы.
но вообще на тему исследований распределенных БД стоит иногда заглядывать на jepsen.io, думаю рано или поздно там появится тест и про 4.0.0.
Мы рассматривали mesos и даже тестировали его до того как решили делать one-cloud.
Mesos на C++. Без шедулера он не работает. Обычно используют связку mesos + marathon, который на java. В реальном большом продакшене ( конкретно у Твиттера ) используется совсем другая связка ( mesos + aurora ).
На момент когда мы на него смотрели, в mesos не было понятия класса изоляции процессов, preemption & scheduling priority, ip per container, распределения трафика и организации сервисов в иерархию. Поддержка распределения дисков в контейнеры в зачаточном состоянии до сих пор. Просто меняя шедулер это туда впилить невозможно.
Для синхронизации миньонов и мастеров mesos использует zookeeper. При массовых авариях это все довольно забавно пытаться заставить работать. Точнее это — один из его фатальных недостатков.
Так что «стабильным», в смысле отказоустойчивости, я бы mesos не назвал.
В «Часть 0.1 Сравнение с VM» строго говоря все сильно не правда. Докер нельзя назвать средством виртуализации ни в коей мере. Он является оберткой вокруг средств контейнеризации ( cgroups + namespaces ) конкретно linux kernel.
В последнее время MS тоже начал что то подобное впиливать в Windows. Но! Контейнеры для linux и windows не совместимы между собой ни в коей мере ( есть решения, запускающие контейнеры linux в других ОС, но они используют отдельные настоящие виртуальные машины с guest os linux в них ).
Подробнее о различиях виртуализации и контейнеризации можно посмотреть здесь: www.youtube.com/watch?v=thcE53dogZk&t=1s&list=PLrCZzMib1e9rZohs_FJg8MK52Ey494z40&index=11
Спасибо за статью. На вопрос про причины модуляризации приложения она правда не отвечает, но опыт перехода на java 9 полезный.
В сухом остатке, как я понял:
1. полностью перевести проект не удалось, проект собирается в 2 артефакта — для java 9 и для java 8. Забавно, что при этом он попал на слайд #WorksFineWithJava9
2. По пути заюзали замечательный Unsafe хак от apangin, который должен знать каждый
3. Переведенные сервера проиграли в CPU 4%, выиграли в памяти занимаемой хипом 15%. Тут правда в статье не указано что за сборщик был в 8 и в 9, как то настраивали их или же эффект достигнут потому, что в 9 какие то дефолты поменялись.
Это немного не то. Я не про использование возможностей java 9 импортировать модули, но при этом свой проект держать в дефолтном/одном модуле ( это достаточно просто как раз ). Я про то чтобы реально попилить свой продукт на модули. Это как раз требует достаточно больших вложений как в разработку, так и в последующее сопровождение.
«гипотетически лучшая структура приложений» вряд ли может быть оправданием возросшей сложности разработки проекта, да и сейчас для веб приложений конкретно для этого модно использовать микросервисные архитектуры ;-)
Аж 2 доклада про миграцию на java 9 модули. А есть реальные люди, не разработчики JVM, которые это собираются делать? Интересно было бы узнать причины.
и m0nstermind не врет, собака ;-). Знания передаются отлично — вот скриншот коммитов в one-nio репу как он виден на внутренней репе ( замазал фамилии людей, которые не apangin и m0nstermind, а то вдруг обидятся ). OpenSource тут как раз вообще не при чем.
Но основная проблема в том, что OpenSource проект нужно продавать и рекламировать, а хорошие евангелисты (те которые доки делают, примеры и ездят по конфам ) так же редки как хорошие программисты, которые понимают в one-nio. А чтобы сразу и то и другое — то это вообще редкий фрукт. Поэтому, либо из хорошего программиста делать маркетолога/евангелиста, либо из маркетолога — программиста. Оба пути как вы понимаете имеют свои минусы ;-) В это имеет смысл вкладываться, если у вас бизнес вокруг этого построен — как у Spring, Cassandra, etc.
Как это влияет ( и влияет ли ) на найм, эффективнее ли это конференций — мне сложно судить. На ум приходит только пример с Disruptor — один их нишевых hpc проектов, чем-то похожий на one-nio, только значительно сильнее распиаренный. Готовы ли вы взять тех, кто его использует на работу делать высокочастотный трейдинг?
Возможно кто-то, у кого был и тот и другой опыт и может сравнить оба подхода и напишет свое мнение? Думаю всем было бы интересно.
Вы про скорость и все такое? Я не большой поклонник бенчмарков и т.п. — они все лгут ( тут картинка с Мюллером ;-) ), да и вас-то интересует не то, как быстро та или иная система выполяют высосанный из пальца бенч, а как та и другая работают с вашей конкретной задачей.
Поэтому лучше сделать тест для своей задачи с реальными данными и сравнить самому как они быстро работают на важных для задачи кейсах.
Идеологически оба как раз разные. hbase работает по модели single-master. То есть в каждый момент времени есть 1 нода, овечающая за каждый регион ключей ( она так и называется — region master). Соотвественно при потере этой нода начинает происходить failover. Во время failover данные региона невозможно ни читать ни писать.
Кассандра же работает по masterless quorum — то есть за «регион» в простейшем случае отвечают не менее 3 нод. При этом запись считается успешной, если большинство нод подтвердит запись. Соответственно, выход из строя одной ноды никак не влияет на работоспособность системы — может и принимать запись и читать. А при использовании спекулятивного ретрая — и на скорость работы системы не влияет.
Cерьезный прирост — это слишком обще. Интересно было бы узнать подробности что было до перехода на scylla и после? Что за данные? Насколько запросы к ним попадают в кеш? Да и общий профиль нагрузки. Не знаю, насколько это влезет все в коммент — может и на статью потянет ;-)
По итогам эксплуатации основная идея видно, что рабочая, за это время было множество мелких инцидентов, да и несколько крупных аварий, что позволило обнаружить и пофиксить множество проблем в основном в Cassandra — gossip (очень нехорошо ведет себя в нестабильной сети), repair, streaming, range tombstones, compaction, всего не упомнишь что потрогали или переписали.
Что, с одной стороны, может напугать, но с другой — подтверждает правильность того, что изначально выбирали движок для хранилища который мы знаем и можем сами поддерживать. Ведь проблемы есть абсолютно со всеми СУБД ( про синие экраны SQL Server рассказывал в лицах на Джокере, если помните ) весь вопрос в том кто и как быстро их может диагностировать и исправлять.
2. нет
Итак:
1. Координатор транзакций и сторадж совмещен. Соотвественно, кратковременные тормоза в подсистеме ввода вывода приводят к тормозам на коммите. В c*one — координатор отделен от стораджа, стораджа составляют отдельный кворум со спекулятивным исполнением, что исключает подобный сценарий.
2. Запись попадает сначала на мастер и потом на все слейвы. Соотвественно если мастер сначала тормознул и потом выключился ( как это обычно и происходит ), то часть изменений будет пропущена, а при возврате такого мастера возникнет «Data branching», который «can be reviewed and the situation be resolved» — как я понимаю вручную. До этого времени, предположу, БД не работает как минимум на запись, а может и на чтение тоже. В c*one такая ситуация невозможна.
3. Выборы взамен отказавшего мастера происходят после обнаружения отказа протоколом raft. про что подробно написано в статье — в c*one выборы не запускаются.
4. Не нашел про партиционирование транзакций ни слова, предположу что мастер глобальный на все транзакции кластера. А как написано «If the master goes down, any running write transaction will be rolled back and new transactions will block or fail until a new master has become available.» означает что до завершения выборов запись данных полностью не работает. В c*one нет единого глобального мастера — их несколько, выборов нет, как уже писал.
5. А вот это намекает на проблемы в масштабировании «All instances in the cluster have full copies of the data in their local database files». Ну или это некорректно сформулировано.
В общем и целом, на основании доки, в neo4j достаточно классический подход к HA, он приблизительно такой же, как и в sql server например.
но вообще на тему исследований распределенных БД стоит иногда заглядывать на jepsen.io, думаю рано или поздно там появится тест и про 4.0.0.
Mesos на C++. Без шедулера он не работает. Обычно используют связку mesos + marathon, который на java. В реальном большом продакшене ( конкретно у Твиттера ) используется совсем другая связка ( mesos + aurora ).
На момент когда мы на него смотрели, в mesos не было понятия класса изоляции процессов, preemption & scheduling priority, ip per container, распределения трафика и организации сервисов в иерархию. Поддержка распределения дисков в контейнеры в зачаточном состоянии до сих пор. Просто меняя шедулер это туда впилить невозможно.
Для синхронизации миньонов и мастеров mesos использует zookeeper. При массовых авариях это все довольно забавно пытаться заставить работать. Точнее это — один из его фатальных недостатков.
Так что «стабильным», в смысле отказоустойчивости, я бы mesos не назвал.
В последнее время MS тоже начал что то подобное впиливать в Windows. Но! Контейнеры для linux и windows не совместимы между собой ни в коей мере ( есть решения, запускающие контейнеры linux в других ОС, но они используют отдельные настоящие виртуальные машины с guest os linux в них ).
Подробнее о различиях виртуализации и контейнеризации можно посмотреть здесь:
www.youtube.com/watch?v=thcE53dogZk&t=1s&list=PLrCZzMib1e9rZohs_FJg8MK52Ey494z40&index=11
В сухом остатке, как я понял:
1. полностью перевести проект не удалось, проект собирается в 2 артефакта — для java 9 и для java 8. Забавно, что при этом он попал на слайд #WorksFineWithJava9
2. По пути заюзали замечательный Unsafe хак от apangin, который должен знать каждый
3. Переведенные сервера проиграли в CPU 4%, выиграли в памяти занимаемой хипом 15%. Тут правда в статье не указано что за сборщик был в 8 и в 9, как то настраивали их или же эффект достигнут потому, что в 9 какие то дефолты поменялись.
«гипотетически лучшая структура приложений» вряд ли может быть оправданием возросшей сложности разработки проекта, да и сейчас для веб приложений конкретно для этого модно использовать микросервисные архитектуры ;-)
виртуалки сознательно отбросили, как технологию еще на ранних обсуждениях
Если это можно назвать кондиционерами ;-)
Но основная проблема в том, что OpenSource проект нужно продавать и рекламировать, а хорошие евангелисты (те которые доки делают, примеры и ездят по конфам ) так же редки как хорошие программисты, которые понимают в one-nio. А чтобы сразу и то и другое — то это вообще редкий фрукт. Поэтому, либо из хорошего программиста делать маркетолога/евангелиста, либо из маркетолога — программиста. Оба пути как вы понимаете имеют свои минусы ;-) В это имеет смысл вкладываться, если у вас бизнес вокруг этого построен — как у Spring, Cassandra, etc.
Как это влияет ( и влияет ли ) на найм, эффективнее ли это конференций — мне сложно судить. На ум приходит только пример с Disruptor — один их нишевых hpc проектов, чем-то похожий на one-nio, только значительно сильнее распиаренный. Готовы ли вы взять тех, кто его использует на работу делать высокочастотный трейдинг?
Возможно кто-то, у кого был и тот и другой опыт и может сравнить оба подхода и напишет свое мнение? Думаю всем было бы интересно.
Поэтому лучше сделать тест для своей задачи с реальными данными и сравнить самому как они быстро работают на важных для задачи кейсах.
Кассандра же работает по masterless quorum — то есть за «регион» в простейшем случае отвечают не менее 3 нод. При этом запись считается успешной, если большинство нод подтвердит запись. Соответственно, выход из строя одной ноды никак не влияет на работоспособность системы — может и принимать запись и читать. А при использовании спекулятивного ретрая — и на скорость работы системы не влияет.