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

Mykola Gurov тролль 28.12.2012 23:43

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

anonymous

reality_hacker 29.12.2012 00:02

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

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

Mykola Gurov тролль 29.12.2012 00:04

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

reality_hacker 29.12.2012 00:06

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

Mykola Gurov тролль 29.12.2012 01:08

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

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

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

reality_hacker 29.12.2012 01:11

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

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

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

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

Mykola Gurov тролль 31.12.2012 18:31

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

reality_hacker 31.12.2012 23:38

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

Mykola Gurov тролль 01.01.2013 03:06

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

reality_hacker 01.01.2013 03:22

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

anonymous 01.01.2013 15:55

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

Smarty Coder 03.01.2013 00:09

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

anonymous 03.01.2013 14:40

Это путь в ад

Smarty Coder

Mykola Gurov тролль 03.01.2013 23:06

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

anonymous

двадцатитрёхлетний сениор 05.01.2013 16:29

А про UTC то вы слышали? :)

anonymous

anonymous 05.01.2013 17:08

Зачем вы травите?

двадцатитрёхлетний сениор 29.12.2012 00:15

Про XA слышали?

anonymous

anonymous 29.12.2012 00:24

Даже не знаю что отвечать.

Василь Приймачук 27.12.2012 17:01

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

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

Нестор Иванович 28.12.2012 08:48

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

Василь Приймачук 28.12.2012 17:28

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

Нестор Иванович

Нестор Иванович 29.12.2012 00:48

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

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

Нестор Иванович 28.12.2012 08:58

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

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

Нестор Иванович 27.12.2012 09:56

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

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

anonymous 27.12.2012 09:22

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

reality_hacker 26.12.2012 22:56

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

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

двадцатитрёхлетний сениор 27.12.2012 00:16

В мускул кластере есть репликация.

reality_hacker 27.12.2012 01:58

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

двадцатитрёхлетний сениор 27.12.2012 09:02

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

reality_hacker 27.12.2012 09:28

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

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

двадцатитрёхлетний сениор 27.12.2012 11:27

Да да, я не я и кластер не моя :)

reality_hacker 27.12.2012 20:39

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

двадцатитрёхлетний сениор 26.12.2012 12:30

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

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

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

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

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

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

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

Smarty Coder 26.12.2012 14:14

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

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

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

двадцатитрёхлетний сениор 26.12.2012 16:08

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

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

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

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

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

Smarty Coder

anonymous 26.12.2012 16:11

-

двадцатитрёхлетний сениор 26.12.2012 16:22

Ну что вы, осваиваю баззворды :-Р

anonymous

reality_hacker 27.12.2012 09:49

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

яплакал

двадцатитрёхлетний сениор 27.12.2012 11:30

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

reality_hacker 27.12.2012 20:40

Счастливо теряться дальше

Василь Приймачук 27.12.2012 17:07

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

Smarty Coder

Нестор Иванович 28.12.2012 09:00

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

Василь Приймачук 28.12.2012 17:35

Ок, можете порадити якусь літературу?

Нестор Иванович

Нестор Иванович 29.12.2012 00:45

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

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

двадцатитрёхлетний сениор 29.12.2012 10:48

Уже есть третье издание.

Нестор Иванович

Нестор Иванович 29.12.2012 11:44

не следил, спасибо.

reality_hacker 27.12.2012 02:01

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

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

двадцатитрёхлетний сениор 27.12.2012 09:15

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

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

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

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

reality_hacker 27.12.2012 09:34

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

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

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

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

двадцатитрёхлетний сениор 27.12.2012 11:30

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

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

reality_hacker 27.12.2012 20:45

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

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

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

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

двадцатитрёхлетний сениор 27.12.2012 21:08

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

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

reality_hacker 27.12.2012 21:10

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

двадцатитрёхлетний сениор 27.12.2012 21:19

Стало быть, не можете.

reality_hacker 27.12.2012 21:21

Могу, 300 баксов в час.

двадцатитрёхлетний сениор 27.12.2012 21:22

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

reality_hacker 27.12.2012 21:23

Та нет, с тобой я отдыхаю, не переживай.

двадцатитрёхлетний сениор 27.12.2012 21:24

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

reality_hacker 27.12.2012 21:25

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

двадцатитрёхлетний сениор 27.12.2012 21:27

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

reality_hacker 27.12.2012 21:31

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

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