У нас есть хорошее приложение под iOS. Первая версия вышла, если не изменяет память под iOS 3 или 4. Постараемся со временем поделиться опытом. Но основная наша работа — код писать, поэтому сроков не обещаем.
Облачные сервисы падают регулярно, это нормально. Мы их используем, но не зависим от одного конкретного.
Использовать две разных БД — дорого. Основные затраты — на экспертизу разработчиков. Команда должна освоить обе БД в достаточной степени, чтобы обеспечить надежность и производительность.
Поэтому мы выбрали БД, которую можно развернуть в любом облаке или дата-центре.
Добрый день, мы пристально Azure Cosmos DB не рассматривали по причине сильной зависимости от одного вендора. Представьте, вдруг она перестала работать — а вам даже позвонить некуда…
По lua — формально вы правы, я неточно выразился. MIT лицензия — свободная лицензия.
Но когда мастер-исходники выложены на github и авторы позволяют сообществу вносить в них исправления — это более открытый подход. Мы таким образом внесли несколько патчей в продукты, которые используем, последний раз — в клиентскую библиотеку NATS.
Более того, я еще не видел ни одной серьезной production-системы, из которой когда-либо не восстанавливали данные вручную. Рано или поздно сбой случится, и надо быть готовым. Спасибо коллеге youROCK, который протоптал эту дорожку для CockroachDB :)
Спасибо за комментарий. Подробно описать нашу инфраструктуру — тема отдельного поста, но вкратце отвечая на ваши вопросы:
60GB — абсолютный объем новых данных, которые нужно ежедневно сохранять (в рабочий день, в выходные поменьше). Бывают пики до 1GB/минуту. Большая часть — неструктурированные данные, которые хранятся отдельно от БД.
В самой крупной таблице около 300 млн записей, и при текущих объемах все вполне может жить в рамках одного мастер-сервера с несколькими репликациями. И, с учетом роста нагрузки, в пределах 12-24 мес тоже будет жить. Скорость хорошая — большинство запросов к БД работают in memory, на application servers — логические кеши, у фронтового nginx — свой кеш.
Но рано или поздно структурированные данные перестанут влезать в одну машину и нужно заранее к этому подготовиться. Поэтому сейчас начнем писать все данные в две базы одновременно и посмотрим, насколько надежно работает выбранный CockroachDB.
Если в течение 3-4 мес все будет без сбоев — начнем потихоньку отключать текущую БД. А если вдруг уровень надежности будет недостаточным — сделаем на PostgreSQL, благо разработчики CockroachDB взяли его диалект для своего языка запросов.
Согласен, любую задачу шардинга можно решить на mysql/postgresql. Но если ее уже за нас решили разработчики БД, включая автоматическую ребалансировку и восстановление при сбоях, и это работает надежно, почему бы этим не воспользоваться?
1) Не совсем. Сложно предсказать характер нагрузки через несколько лет. Поэтому какой бы алгоритм шардирования ни выбрать, рано или поздно придется делать ребалансировку. Хочется выбрать БД, которая умеет делать ребалансировку (менять алгоритм шардирования и соответственно переносить данные) на лету. Если таких не найдется или они будут недостаточно надежны в production — придется вернуться к mySQL/PostreSQL.
2) Мы делаем ставку на то, что он станет production ready в обозримое время (в ближайший год, например). Это осознанный риск, который мы можем себе позволить — мы никуда не торопимся. А статья скорее повышает доверие к нему — ведь про многие альтернативы аналогичных статей «как я восстановил данные» — не находится.
Мы слышали восторженные мнения о GridGain от бизнес-людей, принявших решение о пилоте, но не слышали/читали никаких мнений от разработчиков. Это немного настораживает.
если сервер вернул не 200 или не вернул ответ, клиент перепосылает запрос. В этом случае у нас будут дубликаты (решается наличием уникального id запроса и базы этих id на стороне сервера)
В конфигурации, когда запрос обслуживает пул идентичных сервисов на разных машинах, для избегания дубликатов нужно синхронизировать все уникальные id запросов между ними. Это усложнение логики, еще одна сетевая задержка, дополнительная обработка ошибок (а если эта синхронизация сбойнула?), итд.
Наверное, это явно не следовало из текста, стоит сказать, что durability не являлось критичным свойством для выбора очереди. И в итоге мы выбрали решение, у которого этого свойства нет.
1) автоматическое переключение маршрутизации на резервный сервис в случае умирания основного (или лучше — прозрачная поддержка пула consumers по каждому topic с маршрутизацией round-robin и автоматическим исключением из пула в случае умирания сервиса);
2) минимизация человеческого фактора при конфигурировании и расширении кластера.
C Redis сравнивали, об этом написано в посте, мы сочли, что он проигрывает NATS по второму критерию.
Все упомянутые решения достаточно производительны/надежны для большинства практических применений. Разница проявляется лишь в краевых случаях.
Спасибо за замечание. Согласен, сформулировано не вполне корректно.
Есть 3 главных показателя скорости внешнего носителя: throughput, latency и IOPS. Когда передаешь много маленьких сообщений, latency выходит на первый план по степени влияния на общую производительность системы.
Из таблички: latency передачи пакета данных по сети: 0.01мс, что позволяет (теоретический предел) передать 100 000 сообщений в секунду.
У SSD latency 0.15мс, и теоретический предел будет 1c / 0.15мс = 6 700 сообщений в секунду. У HDD latency выше и к-во сообщений в секунду будет еще меньше.
Конечно, на фактическую производительность влияет много факторов. Например, если сообщений в MQ мало, все они большого размера и передаются не на сервер в соседней стойке, а на другой континент — то throughput может оказаться важнее.
Даже использовали, нареканий нет. Субъективно, API немного проще 0MQ, производительность сравнимая с 0MQ. Но надо самим писать логику service discovery. Да и автор nanomsg перестал поддерживать проект. В github есть коммиты сообщества, конечно, но последние 3 мес (с января 2017) ни одного. Решили не рисковать.
«бороться с повторными доставками» — я имел в виду адресат должен самостоятельно отслеживать и (чаще всего) игнорировать, когда ему доставили сообщение повторно.
Спасибо. Нам нужен кластер, из общих соображений решили, что N процессов могут сбойнуть с меньшей вероятностью, чем 2N.
NATS — at most once delivery.
NSQ — at least once delivery.
В случае at least once нужно самому бороться с повторными доставками.
В NATS понравилась фича принудительное отключение «slow consumer» ради защиты кластера. Это и отсутствие гарантии доставки мотивирует писать надежных consumers.
Компоненты могут быть написаны на разных ЯП. В стандартных in-memory очередях обычно нет логики сетевого переподключения к другому адресату, когда текущий адресат умер.
Про производительность соглашусь с VlastV — вопрос к автору тестов. Мы же искали не самое производительное решение, а «good enough» для наших задач.
Использовать две разных БД — дорого. Основные затраты — на экспертизу разработчиков. Команда должна освоить обе БД в достаточной степени, чтобы обеспечить надежность и производительность.
Поэтому мы выбрали БД, которую можно развернуть в любом облаке или дата-центре.
Однако обещания у них заманчивые. )
По lua — формально вы правы, я неточно выразился. MIT лицензия — свободная лицензия.
Но когда мастер-исходники выложены на github и авторы позволяют сообществу вносить в них исправления — это более открытый подход. Мы таким образом внесли несколько патчей в продукты, которые используем, последний раз — в клиентскую библиотеку NATS.
60GB — абсолютный объем новых данных, которые нужно ежедневно сохранять (в рабочий день, в выходные поменьше). Бывают пики до 1GB/минуту. Большая часть — неструктурированные данные, которые хранятся отдельно от БД.
В самой крупной таблице около 300 млн записей, и при текущих объемах все вполне может жить в рамках одного мастер-сервера с несколькими репликациями. И, с учетом роста нагрузки, в пределах 12-24 мес тоже будет жить. Скорость хорошая — большинство запросов к БД работают in memory, на application servers — логические кеши, у фронтового nginx — свой кеш.
Но рано или поздно структурированные данные перестанут влезать в одну машину и нужно заранее к этому подготовиться. Поэтому сейчас начнем писать все данные в две базы одновременно и посмотрим, насколько надежно работает выбранный CockroachDB.
Если в течение 3-4 мес все будет без сбоев — начнем потихоньку отключать текущую БД. А если вдруг уровень надежности будет недостаточным — сделаем на PostgreSQL, благо разработчики CockroachDB взяли его диалект для своего языка запросов.
Согласен, любую задачу шардинга можно решить на mysql/postgresql. Но если ее уже за нас решили разработчики БД, включая автоматическую ребалансировку и восстановление при сбоях, и это работает надежно, почему бы этим не воспользоваться?
2) Мы делаем ставку на то, что он станет production ready в обозримое время (в ближайший год, например). Это осознанный риск, который мы можем себе позволить — мы никуда не торопимся. А статья скорее повышает доверие к нему — ведь про многие альтернативы аналогичных статей «как я восстановил данные» — не находится.
Мы ее не изучали, но на сайте сходу не смог понять, как устроено ценообразование.
Если есть реальный опыт с ней, было бы интересно почитать впечатления.
В конфигурации, когда запрос обслуживает пул идентичных сервисов на разных машинах, для избегания дубликатов нужно синхронизировать все уникальные id запросов между ними. Это усложнение логики, еще одна сетевая задержка, дополнительная обработка ошибок (а если эта синхронизация сбойнула?), итд.
Наверное, это явно не следовало из текста, стоит сказать, что durability не являлось критичным свойством для выбора очереди. И в итоге мы выбрали решение, у которого этого свойства нет.
1) автоматическое переключение маршрутизации на резервный сервис в случае умирания основного (или лучше — прозрачная поддержка пула consumers по каждому topic с маршрутизацией round-robin и автоматическим исключением из пула в случае умирания сервиса);
2) минимизация человеческого фактора при конфигурировании и расширении кластера.
C Redis сравнивали, об этом написано в посте, мы сочли, что он проигрывает NATS по второму критерию.
Все упомянутые решения достаточно производительны/надежны для большинства практических применений. Разница проявляется лишь в краевых случаях.
Есть 3 главных показателя скорости внешнего носителя: throughput, latency и IOPS. Когда передаешь много маленьких сообщений, latency выходит на первый план по степени влияния на общую производительность системы.
Из таблички: latency передачи пакета данных по сети: 0.01мс, что позволяет (теоретический предел) передать 100 000 сообщений в секунду.
У SSD latency 0.15мс, и теоретический предел будет 1c / 0.15мс = 6 700 сообщений в секунду. У HDD latency выше и к-во сообщений в секунду будет еще меньше.
Конечно, на фактическую производительность влияет много факторов. Например, если сообщений в MQ мало, все они большого размера и передаются не на сервер в соседней стойке, а на другой континент — то throughput может оказаться важнее.
Вот тут есть сравнение latency для разных MQ:
http://bravenewgeek.com/benchmarking-message-queue-latency/
Из интересных наблюдений:
— у NATS и Redis лучшие значения показателя latency (стабильно меньше 1мс), но он растет при увеличении размера сообщения
— у RabbitMQ и Kafka показатель latency начинает быстро расти в районе 99,0-99,9 перцентилей даже при маленьких сообщениях
В каждом случае выбор решения для MQ, очевидно, зависит от конкретных требований и решаемых задач.
NATS — at most once delivery.
NSQ — at least once delivery.
В случае at least once нужно самому бороться с повторными доставками.
В NATS понравилась фича принудительное отключение «slow consumer» ради защиты кластера. Это и отсутствие гарантии доставки мотивирует писать надежных consumers.
Про производительность соглашусь с VlastV — вопрос к автору тестов. Мы же искали не самое производительное решение, а «good enough» для наших задач.