×Закрыть

Як ви синхронізуєте бази?

Соррі за офтоп, хоча це cosmo для програмерів, :) але пропоную обговорити наступне питання: як краще синхронізувати бази данних на багатьох сервантах?

Перш за все MySQL Cluster — наскільки він гарний, хтось може поділитись досвідом використання? Пишуть, що запити виконуються повільніше, а JOIN набагато повільныше, до того ж серевер повинен мати достатньо пам’яті щоб вміщувати всю базу. Не велике діло, але це добавляє турбот з апгрейдами.

Хтось використовує Сassandra? Апач обіцяє «linear scalability».

Якщо ваша совтина працює з різними БД, наприклад ч-з ODBC. Накопав ось таке рішення www.symmetricds.org Хтось пробував?

Можливо хтось має якісь in-house рішення?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я пользуюсь www.devart.com/ru/dbforge и пишу скрипты.

оффтоп Есть транзакции которые не синхронизируются в принципе — вот где проблема.

оффтоп Есть транзакции которые не синхронизируются в принципе — вот где проблема.

например?

Отпустили товар в двух базах которого была одна штука. Поменяли цену на один и тот же товар. Короче, всё что должно быть блокированно при изменении.

Если бы у тебя была синхронная репликация таких бы ситуаций наверное не было бы.

Так может ему А или П не нужны?

Может. Но жертвует C со слов.

А, в этом смысле. Ну в принципе решения есть конечно, но да — в тупую не засинхронизируешь.

Нет решения. Именно поэтому NoSQL и всяческие облака это базы для одной* таблицы. Или ты блокируешь транзакции и поддерживаешь целостность или лучник может проходить через стену.

*да, да, успокойтесь, для двух.

Не могу полностью согласиться. Есть жизнь и без полной транзакции. Лучника просто нужно отловить, см. например vector clock в Riak . Или ввести КПП на опушке при помощи CQRS / event bus. Другое дело что это часто затрагивает архитектуру всего решения, а не спрятано в уютном мирке баз данных.

Лучника просто нужно отловить, см. например vector clock в Riak

А как именно клок вектор позволяет выкручиваться там где нужны транзакции?

Сначала уточню что значит «нужны транзакции»? И почему они нужны?

Ну типично с одного экаунта переписывают деньги на другой, нужно что бы записи не перезатерлись конкурентными запросами и что бы если одна из операций зафейлится по какой то причине транзакция откатилась поностью.

Ну типично техническая постановка задачи в сферическом вакууме. В жизни все не совсем так. Начиная с формальных придирок что

если одна из операций зафейлится по какой то причине транзакция откатилась поностью.

не должно быть, так как отметка про неудачную операцию остается. Потом «записи» собственно финансовых транзакций как правило не перетираются ибо есть неизменяемыми и отдельными от баланса счета. С балансом вектор как раз очень прекрасно помогает, объяснять?

Ну типично техническая постановка задачи в сферическом вакууме.

Та нет, абсолютно жизненная ситуация абстрагированная от технических деталей.

С балансом вектор как раз очень прекрасно помогает, объяснять?

Я не пoнял какой именно подход ты собираешься использовать, поэтому обьяснение не помешало бы.

Кстати да, не так просто как мне казалось. Без дополнительных телодвижений типа записи предыдущего значения и timestamp его, автоматически не разрулить. Так что остается vector clock в основном признаком конфликтной ситуации, а для разрешения — смотреть в лог и (полу-)автоматически пересчитывать заново.

Если ты еще рассмотришь вариант требований когда нельзя допускать выхода в минуса значения на экаунте, то окажется что вектор клок даже в таком варианте недостаточен, нужен какой то лок или compare and swap.

Думаешь, на твоей дебитной карточке не может быть негативного остатка? ;)

не знаю, расскажи мне про мою дебетную карточку

Я бы такому комменатрию присвоил бы статус «Комментарий года» Не столько из-за смыслового контекста сколько из-за времени размещения.

ага, порівнювати тайм-штампи це рішення

Чем ближе к бездне, тем выше ставки.

Ви спочатку визначтесь що вам треба.
1. Якщо Ваша база невелика, і вам потрібно просто збільшити пропускну здатність — в такому випадку master-slave реплікація.
2. Якщо у Вас потенційно великий об’єм даних, що не поміститься на одній машині — тут необхідний sharding.

P.S. Я не знаю як це можна зробити в MySQL. Якщо вам потрібна master-master реплікація і повна синхронізація даних — поки-що найкраще це виходить в CouchDB (BigCouch).

как у коача с перфомансом нынче? Когда щупал это был ппц

А яку версію Ви пробували?
З перформансом все те ж саме. В 1.2.0 підкрутили механізм view, тестів не бачив, суб’єктивно шустріше все працює, но в порівнні з тим же MySQL не фонтан.

мм непомню уже. двухлетней где то давости. Было грусно и так и по тестам.

база красивая концептуально но из за этой же концепции тормозная

мастер -мастер репликация в mysql делается за 10 минут. не без некоторых подводных камней в будущем- но все очень просто. Нужен просто нормальный dba что бы соломки подстелить.

Правда было бы еще круто понимать зачем нужа именно мастер-мастер.

в лоб и без кластера — смотрите в сторону mysql replication и DRBD

постройте тестовую конфигурацию, поиграйтесь. Это конечно немного хардкорно но вроде как довольно дубово и прозрачно.

Имело смысл при разработке сразу закладывать кластерную БД, причем делать это желательно непосредственным испытанием кандидата на специально написанном на коленке api-neutral тесте (ODBC/PHP). Решений существует много, все рабочие и вопрос обычно лежит в плоскости стоимости и/или вытекающей сложности применения того или иного продукта. Если продукт еще разрабатывается — то имеет смысл глянуть в сторону NuoDB, она пока сыровата, но с грехом пополам задачи кластерной БД выполняет, имея при этом много преимуществ над другими решениями [ за исключением, пожалуй, цены ;) ]

К слову ни MySql cluster ни Cassandra это не способы синхронизировать БД.

А ответ на вопрос как уже заметили — репликация, есть у всех нормальных БД.

Я как бы в курсе, и в кассандре есть репликация и еще в куче тулов, которые при этом не есть средствами синхронизации БД.

В первом посте вы пишете: у кластера и кассандры нет возможностей для синхронизации БД, но для синхронизации БД надо использовать репликацию, которая есть у кластера и кассандры. Что я понимаю не так? :)

В первом посте вы пишете: у кластера и кассандры нет возможностей для синхронизации БД

это бред, я такого не писал, учись читать.

Ну если ты читать принципиально не хочешь учится, то кластер действительно не твоя

Самый топорный вариант — воткните репликацию. Быстро, сердито, компромиссно по тормозам. Но делать это средствами мускуля несколько неудобно, если у вас > 3 сервера. Потому посмотрите в сторону Galera Cluster — тулза для продвинутой репликации мускуловых баз, решает кучу головняка.

Что касается мускул кластера — то он весьма тяжелый и подходит не для всех случаев жизни. Если у вас, скажем, несложная OLTP система, то можно обойтись и без него. К тому же, если у вас изначально всё писалось без задела на использование этой тулзы, то могут (и таки будут!) повылезать бока с бинарными журналами, ключами, и ещё куча тонкостей. Тоесть, нельзя просто так взять и поставить mysql cluster :) В целом же, решение довольно неплохое, и вполне юзабельное.

Опять же, определитесь, что вам надо: высокую доступность или бекап\дублирование данных? Если первое — мускул кластер или аналогичное решение, если второе — решения на основе репликации.

Как годную альтернативу рекомендую решение от Percona — оно более удобно в использовании и администрировании, лишено некоторых детских болезней мускуля и, по тестам, в целом шустрее.

Что касается кассандры: многие не всегда используют её по назначению, и тем самым, ловят фан от тормозов. Кассандра хороша, когда вам надо очень много пихать, мало брать, и потом неспеша что то с напиханным делать. Если вам только хранить — кассандра, если хранить и оперировать — ашбейс, если просто замену мускулу — монгодб.

Для работы софта с несколькими БД писался свой велосипед, потому, чего то дельного и опробованного порекомендовать не смогу.

Вообще, лучше более подробно опишите вашу проблему, а то сильные стороны описанных решений могут быть для вас слабыми, неподходящими или вовсе неприменимыми, уверенно советовать тут — как пальцем в небо.

сейчас 2 базы на разных серверах, изменения могут вносится в любую из этих баз, пока что использутеся MySQL, но закладываем возможность работать с разными базами, потому используем ODBC.

В данный момент второй это fail-over сервер, но в будущем (надеюсь) количество будет увеличиватся и нагрузка будет распределятся.

В принципе, есть свой велосипед, который синхронизирует изменения, но не хочтеся «пропустить поезд», чтоб потом тыкали пальцами и говорили типа, что «не используют современные технологии»

В прогрессивном мире использование ODBC считается непопулярным по многим причинам.

Если у вас начался период апгрейда ПО под растущие нагрузки — сразу спланируете, какие хранилища данных будете использовать и в каком виде, и под них же используйте специфичные драйвера, это позволит добиться большей производительности, а так же позволит юзать %DBMS%-специфичные фичи, писать более понятный и краткий код. Как показывает практика разработки нагруженных проектов, такое решение вполне себя оправдывает при грамотном планировании, а вот «универсальность» интерфейса уже вылезала боком. Отказываться от таких вещей в пользу универсальности ODBC — сомнительного рода действо. В конце концов, критически важные места можно писать таким образом, чтобы небыло проблем при переключении между СУБД, использовать сапомисные DBAL, прогонять через тесты совместимости с ODBC.

В вашем случае, рекомендую рассмотреть связку mysql + haproxy/mysql proxy для балансировки нагрузки и способ репликации, описанный мной в первом посте, для обеспечения распределения данных. Так же, рассмотрите возможность секционирования (можно заюзать hibernate shards), это позволит в будущем разгрузить схему репликации, сеть и железо, отдав мастер-серверам в бекграунд по слейву, который будет «на подхвате». Если хотите «по хардкору» — можно пойти дальше и пробовать DRBD.

Так же стоит напомнить, что с ростом количества серверов баз данных встанет вопрос об актуальности данных на каждом из них, потому придётся этот момент учитывать: либо проектировать систему так, что это будет не критично, либо юзать хотя бы полусинхронную репликацию, или выкатить критические таблицы в solidDB, что скорости тоже не добавит.

Больше полезной информации врядли получится подсказать, так как дальнейшие рассуждения требуют уже деталей системы и будут системозависимы.

Да вы таки синьор в БД — читаю и учусь просто:)

рассмотрите возможность секционирования (можно заюзать hibernate shards), это позволит в будущем разгрузить схему репликации, сеть и железо, отдав мастер-серверам в бекграунд по слейву, который будет «на подхвате»

яплакал

А тут вам что не нравится? Я прямо теряюсь в догадках...

Хм, цікаво. Вам потрібна master-master реплікація. Тут буде складніше. Краще візьміть варіант master-slave: всі дані пишуться на одну ноду(master), і копіюються на інші (slave). З slave можна тільки читати. Думаю MySQL Cluster так і побудований.
Якщо ж вам такий варіант не підходить, тоді подивіться на CoucDB, інших баз даниз з master-master реплікацією я не бачив поки-що.

Ок, переставайте давать советы по вопросам в которых так драматически не разбираетесь.

можно например такое почитать — shop.oreilly.com/...780596101718.do В свое время эта книженция меня крепко выручила.

Но вообще практика лучший учитель

Что касается кассандры: многие не всегда используют её по назначению, и тем самым, ловят фан от тормозов. Кассандра хороша, когда вам надо очень много пихать, мало брать, и потом неспеша что то с напиханным делать.

Это с чего ты такое взял? К слову кассандра и hbase устроены приблизительно одинаково в плане пихания данных, и паттерны тормозов у них тоже одинаковые.

mysql и postgresql устроены приблизительно одинаково в плане писания данных, и паттерны тормозов у них тоже одинаковые.

Ну ёпт, а как ты думаешь? hbase создавался с умыслом не только быстро пихать, но и быстро извлекать, ибо мап\редюс и всё такое, кассандра же — только очень быстро пихать.

Хочешь циферок — погугли, весь интернет пестрит табличками, что круче и под какие нужды. Не буду же я тут расписывать все тонкости, дал человеку ориентировку — пусть разбирается, что ему больше подходит.

hbase создавался с умыслом не только быстро пихать, но и быстро извлекать, ибо мап\редюс и всё такое, кассандра же — только очень быстро пихать.

Это бред, кончай курить.

Хочешь циферок — погугли, весь интернет пестрит табличками, что круче и под какие нужды. Не буду же я тут расписывать все тонкости, дал человеку ориентировку — пусть разбирается, что ему больше подходит.

Вот те циферки, на всех бенчмарках где есть чтение кассандра и хбейс идентичны, там где только запись хбейс выигрывает потому что буферизирует записи на клиенте. Сам бы погуглил вначале прежде чем бред нести.

adhocshare.blogspot.com/...parison-of.html

Цихверки подтверждают мои слова: по чтению кассандра сливает ашбейсу, причём, ощутимо, ч.т.д.

Раз ты такой умный — так предложи ТС решение проблемы :)

Цихверки подтверждают мои слова: по чтению кассандра сливает ашбейсу, причём, ощутимо, ч.т.д.

Та ты шо, первый же график где есть чтение, кассандра 33тыс опс/сек, хбейс 35 тыс опс сек, и в других тестах точно такая же фигня.

Раз ты такой умный — так предложи ТС решение проблемы :)

Решение проблемы должно быть такое, что бы умел их одминчег.

Решение проблемы должно быть такое, что бы умел их одминчег.

Стало быть, вам по делу сказать нечего?

Почему, есть. Моя миссия здесь — разоблачить шарлатанов сыплющих базворды вроде тебя.

Я вас в убыток своим невежеством ещё не загнал?

А, ну тогда развлекайтесь, не мешайте только взрослым дядям проблемы решать.

Что ты, я только помогаю. Ты вот написал много ерунды, а я дядям обьяснил что это ерунда.

А вдруг не ерунда? Надо было альтернативу предлагать, а то опровергать все мастера. А, да, 300 баксов, я помню, думать — только за деньги.

Тут на некотором абстрактном уровне альтернатив уже предложили, репликация, мультимастер и все такое. Проблема в том что из описания ТС не понятно что у него там вообше происходит, размер базы, трафик на нее, базы расположены в разных датацентрах или нет, виды запросов, требования к latency, availability etc, от всех этих факторов очевидно и должно зависеть решения.

Но у ТС к сожалению поток сознания, и что бы его разгрести нужно потрудится, а это стоит денег и мне лень.

угу, без нормального описания что там происходит — это все словесный анонизм. Есть подозрение что ОП пока просто не знает сам что у него там творится и просто хочет кластера.

По этому я просто бы отправил разбиратся со схемами репликации...

Подписаться на комментарии