Быстрая масштабируемая ACID NoSQL замена такой SQL таблице...
Имеется MySQL 5.5 InnoDB таблица "каждая_строка_это_реальные_деньги" со столбцами:
- неуникальный ключ поиска (может выбрать несколько строк, выбор одной из них на стороне Java клиента по атрибутам) BIGINT (long),
- уникальный PK BIGINT (long) – используется как «пассивный» атрибут и активно - для удаления отработанных строк,
- datetime добавления в таблицу,
- несколько столбцов аттрибутов (коротенькие строчки, числа).
На двух серверах настроена master-master репликация = бакап и масштабирование.
Когда нагрузка спадает, запускается job удаляющий строки старее X дней, где X константа выбираемая один раз от 1 (большинство строк обрабатывается = удаляется в течении дня) до 10 (трясемся над каждой копейкой).
Количество строк 100-200 млн (сейчас гораздо меньше и хотелось бы не иметь жесткой верхней границы).
Средняя скорость добавления и удаления (одновременно, многопоточно) 1000 строк/сек. В пике 5000 строк/сек (сейчас меньше и также хотелось бы иметь границу выше, про запас). Добавляем строку, через некоторое время она обрабатывается и удаляется. Небольшой процент не обрабатывается – протухает и удаляется вышеупомянутым job-ом.
ACID обязательно – потеря строки, это потеря реальных денег (старые удаляются, но они просрочены и денег всё равно уже не будет).
MySQL 5.5 InnoDB таблица - всем хороша, но два серьезных минуса:
- master-master репликация далека от идеала: ограничивает всё масштабирование двумя серверами, нетороплива, не любит временных потерь связи между серверами,
- удивительно, но хоть в тестах MySQL дает скорости 10 000 строк/сек, в практической эксплуатации скорости ниже и могут сильно прыгать.
MySQL настроен хорошим админом (Петр Зайцев ничего дополнительно посоветовать не смог), т.е. скорее всего всё уже выжато.
В проекте для другого используется ehcache – замечательная штука, но не подходит, я специально консультировался на их форуме – это именно кеш «потеряли строку, ну ладно – добавят заново».
Почему задаю вопрос: NoSQL много, в рекламных статьях все замечательные, бенчмарки загляденье, предварительное тестирование показывает хорошие результаты, но – тадам! - реальная эксплуатация под большими нагрузками обнаруживает совершенно другой продукт.
В прошлом году тестировали ActiveMQ, RabbitMQ, HornetQ – отличные продукты для доклада на HIGHLOAD и поста на Хабре - по факту просрана куча времени, сейчас чистим код от всех упоминаний одного из этих замечательных продуктов.
Нет времени повторять этот замечательный эксперимент с NoSQL ;-(
Поможите люди добрые...
UPD1: из текста это следовало неявно, уточню: сервера разнесены по разным датацентрам, т.е. возможно пропадание связи между серверами и большой пинг.
Это, вероятно, отбрасывает решения типа hazelcast, Infinispan, etc - я спрашивал у разработчиков hazelcast, они сказали, что решение для "все сервера кластера в одной локалке".
UPD2: это же чуть ли не идеальный кейз для внедрения NoSQL, в интернетах пишут про десятки тысяч вставок в секунду...
UPD3: бакап для бакапа (локальный внутри каждого хостинга) разумеется есть.
master-master нужен потому, что мы живем в реальном мире, где ВСЕ хостинги бывают недоступны - полностью, либо из некоторых регионов. В нормальной ситуации ПО работает с локальным MySQL.
Но вот один из датацентр умер с извинительным письмом клиентам. С master-master репликацией "пара кликов мышкой" и упавшее знамя подхватил другой датацентр, до этого не интересовавшийся "чужими" данными приходящими по репликации.
- неуникальный ключ поиска (может выбрать несколько строк, выбор одной из них на стороне Java клиента по атрибутам) BIGINT (long),
- уникальный PK BIGINT (long) – используется как «пассивный» атрибут и активно - для удаления отработанных строк,
- datetime добавления в таблицу,
- несколько столбцов аттрибутов (коротенькие строчки, числа).
На двух серверах настроена master-master репликация = бакап и масштабирование.
Когда нагрузка спадает, запускается job удаляющий строки старее X дней, где X константа выбираемая один раз от 1 (большинство строк обрабатывается = удаляется в течении дня) до 10 (трясемся над каждой копейкой).
Количество строк 100-200 млн (сейчас гораздо меньше и хотелось бы не иметь жесткой верхней границы).
Средняя скорость добавления и удаления (одновременно, многопоточно) 1000 строк/сек. В пике 5000 строк/сек (сейчас меньше и также хотелось бы иметь границу выше, про запас). Добавляем строку, через некоторое время она обрабатывается и удаляется. Небольшой процент не обрабатывается – протухает и удаляется вышеупомянутым job-ом.
ACID обязательно – потеря строки, это потеря реальных денег (старые удаляются, но они просрочены и денег всё равно уже не будет).
MySQL 5.5 InnoDB таблица - всем хороша, но два серьезных минуса:
- master-master репликация далека от идеала: ограничивает всё масштабирование двумя серверами, нетороплива, не любит временных потерь связи между серверами,
- удивительно, но хоть в тестах MySQL дает скорости 10 000 строк/сек, в практической эксплуатации скорости ниже и могут сильно прыгать.
MySQL настроен хорошим админом (Петр Зайцев ничего дополнительно посоветовать не смог), т.е. скорее всего всё уже выжато.
В проекте для другого используется ehcache – замечательная штука, но не подходит, я специально консультировался на их форуме – это именно кеш «потеряли строку, ну ладно – добавят заново».
Почему задаю вопрос: NoSQL много, в рекламных статьях все замечательные, бенчмарки загляденье, предварительное тестирование показывает хорошие результаты, но – тадам! - реальная эксплуатация под большими нагрузками обнаруживает совершенно другой продукт.
В прошлом году тестировали ActiveMQ, RabbitMQ, HornetQ – отличные продукты для доклада на HIGHLOAD и поста на Хабре - по факту просрана куча времени, сейчас чистим код от всех упоминаний одного из этих замечательных продуктов.
Нет времени повторять этот замечательный эксперимент с NoSQL ;-(
Поможите люди добрые...
UPD1: из текста это следовало неявно, уточню: сервера разнесены по разным датацентрам, т.е. возможно пропадание связи между серверами и большой пинг.
Это, вероятно, отбрасывает решения типа hazelcast, Infinispan, etc - я спрашивал у разработчиков hazelcast, они сказали, что решение для "все сервера кластера в одной локалке".
UPD2: это же чуть ли не идеальный кейз для внедрения NoSQL, в интернетах пишут про десятки тысяч вставок в секунду...
UPD3: бакап для бакапа (локальный внутри каждого хостинга) разумеется есть.
master-master нужен потому, что мы живем в реальном мире, где ВСЕ хостинги бывают недоступны - полностью, либо из некоторых регионов. В нормальной ситуации ПО работает с локальным MySQL.
Но вот один из датацентр умер с извинительным письмом клиентам. С master-master репликацией "пара кликов мышкой" и упавшее знамя подхватил другой датацентр, до этого не интересовавшийся "чужими" данными приходящими по репликации.
