Pull to refresh
16
0
Колосов Алексей @Softovick

Пользователь

Send message
На мой взгляд, выбор системы, которая распространяется только на платной основе, должен быть аргументированным решением. Но по опыту чаще всего использование таких продуктов выглядит скорее выбором менеджмента или уже используемое ПО диктует свои условия — либо ты делаешь на этом, либо вообще не занимаешься проектом. И хоть обдаказывайся, что Oracle Database круче всех, а у заказчика инфраструктура на IBM Notes… Ну врядли. А теперь покажите мне небольшой проект, который способен выкупить лицензию на Oracle Database.
Я вас удивлю, но это не так. А если быть более точным, не совсем так. Если коротко, это инфраструктура, где есть и почтовый сервер, клиент и СУБД и сервер приложений и офисный пакет (он там был не всегда). Причем сервер приложений есть и в клиенте и в серверной части.
Ну да, упадет один из мастеров и весь кластер недоступен… Это также работает и при большем, чем 3 мастера, количестве узлов?
Это что-то типа усиленной транзакции?
Думаю это совсем другая тема для отдельной статьи…
Все верно :) Хотя и специально уточнял, что статья моя не для таких случаев.
Спасибо… А что за ограничение на объем данных, какого порядка?
Ну не считая того, что та статья 2013 года… Говорится там примерно о том же самом :) Или нет?
Хорошее уточнение. А что вы можете о них рассказать?
То есть все таки четное количество? Или это связано с объемом данных?
А вы используете где-то такой кластер Redis?
Верно. Надо подправить статью, спасибо за уточнение.
Отличный пример! И он как раз о том, что решение достаточно нишевое, где альтернатив не так уж и много. Спасибо за описание, пригодится.
Да, хорошая. Но меня лично напрягла ситуация с ее закрытием в конце 2016 года. Потом ее выкупили и снова начали поддерживать в начале 2017… Но у меня осадочек остался.
Couchbase как бы тоже не совсем тоже самое, что и CouchDB… Надо подправить описание, речь про хранение документов без схемы конечно же.

Про Redis речь не о репликации мастер-ведомый. Как раз репликация там очень хорошо сделана. Чтобы создать кластер и распределить данные между несколькими узлами, нужно иметь количество узлов, кратных 3 обязательно. Создавать и добавлять узлы в кластере можно только при помощи скрипта специального на Ruby. И встречал упоминание, что работает это не всегда корректно и очевидно. Это все не очень удобно — нельзя например создать кластер из 5 узлов или просто добавить 1 мастер, убрав другой мастер. Ах да, узлы еще должны работать с опцией cluster-enabled, при этом как обычные сервера они уже перестают быть доступными. Довольно неудобное решение. Если я ошибаюсь, поправьте меня.
Дополнил по поводу MySQL, InnoDB. Судя по всему некоторые восприняли не совсем верно мое описание (или я не совсем ясно выразился для человека).
Я читал про нее. Но вот рекомендовать в качестве БД для проекта… По описанию она предназначена для достаточно узкой ниши, обработки аналитических запросов. Она используется в Яндексе где только можно, но вот так чтобы кто-то еще помимо использовал, не встречал. Только упоминание про ЦЕРН и ТинкоффБанк. И там данные огого какие огромные, масштабы совсем не маленькие. У вас есть опыт реального использования?
Server version: 5.5.57-38.9 Percona Server (GPL), Release 38.9
Достаточно свежая?
Я не зря упомянул коммерческую поддержку от разработчиков. Она есть по моему в каждой из перечисленных СУБД. Насколько круче она в MS или Oracle — не знаю, но если у вас нет никакой СУБД, то чисто платную выбирать нужно только в том случае, если выбор оправдан.
Спасибо. Но возник вопрос, насколько лучше стало? Ну то есть совсем надежно или чуть надежнее? Ну вот например на уровне с PostgreSQL или все же не стоит сравнивать?

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity