Хроника Карта против Редис против Колобоке
У нас есть система, в которой один и тот же набор данных (пары ключ-значение) используется на 50 серверах. Количество обновлений в этом наборе данных составляет примерно 1000 в час и должно быть реплицировано на эти 50 серверов. У нас есть главная система, которая получает эти обновления и отвечает за распространение этих обновлений на другие серверы. В настоящее время мы синхронизируем весь набор данных (а не инкрементные обновления) со всеми серверами каждый час в форме файлов. Эти данные затем загружаются в неизменные карты Колобоке. Каждый сервер обрабатывает около 25000 запросов в секунду, и каждый запрос выполняет 30 просмотров этой карты. Средняя задержка ответа на запросы, полученные на этих серверах, должна составлять максимум около 3 миллисекунд, и, следовательно, карты колобка в памяти хорошо помогают нам поддерживать это время ответа.
Однако наша текущая система для синхронизации этих данных между серверами вызывает проблемы:
1) Чаще всего происходит сбой синхронизации этих важных данных на одном из серверов, что приводит к потере дохода
2) Поскольку эти данные хранятся в памяти, они не являются постоянными, и нам необходимо повторно загружать эти данные каждый раз при перезапуске сервера или при каждом ежечасном обновлении, что влияет на время запуска приложения.
Чтобы сделать это более эффективным, я исследовал карты Redis, Chronicle Maps и Mutable в библиотеке Koloboke. Но я столкнулся с ограничениями со всеми из них:
Redis: Redis поддерживает репликацию и постоянство. Однако, используя его утилиту для сравнения, я обнаружил, что число поисков, которые она может поддерживать, лишь немного превышает наш средний сценарий использования (0,8-1,1 миллиона запросов против 0,75 миллиона, что является нашим числом просмотров в секунду). Более того, вызовы redis будут выполняться по сети, что повредит нашему среднему времени отклика 3 мс.
Карты хроники. Изучив этот вопрос, я обнаружил, что Карты хроники поддерживают репликацию, постоянство и могут обслуживать до 30 миллионов запросов в секунду. На первый взгляд это показалось хорошим вариантом, но позже я обнаружил, что они плохо работают с мультикартами, и мы генерируем их в нашем приложении. Кроме того, они хранят данные вне кучи, и, следовательно, стоимость десериализации данных может привести к снижению производительности.
Koloboke: его производительность хорошая и подходит для нашего случая использования, но не поддерживает репликацию и постоянство.
Я не смог найти ничего, что поддерживало бы все наши варианты использования. Я ищу предложения от этого сообщества, которые могут помочь нам эффективно построить эту систему, не оказывая серьезного влияния на производительность. Любая помощь по этому вопросу будет высоко ценится! Спасибо!
1 ответ
Этот вариант использования может быть легко обработан в Aerospike. Aerospike может быть настроен так, чтобы запускать именно эти серверы. Aerospike обновит все серверы для вас, когда вы сделаете одно обновление для кластера серверов. На первый взгляд, ваши требования к задержке чтения также приемлемы для Aerospike. Кроме того, Aerospike может предоставлять вам данные как из ОЗУ, так и одновременно сохранять их на SSD или HDD для постоянного хранения. Похоже, сделанный на заказ чехол для Aerospike. Вы можете бесплатно запустить проверку концепции, используя Aerospike Community Edition. Или, если вы хотите получить пробную лицензию Enterprise Edition в течение 3 месяцев и помочь команде Aerospike Solution Architecture, обратитесь в отдел продаж Aerospike. Чтобы сделать это успешно, вы должны правильно настроить кластер Aerospike как для объема данных, так и для задержки данных. Если вы неправильно настроите конфигурацию, вы можете отклонить решение, которое будет работать на вас.