С удовольствием!
Прогресс — непрерывное поступательное движение вперёд.
И да, опыт использования для мелких проектов есть, функциональную часть я имел возможность оценить
Касательно нагруженных проектов — пока опыта нет, к сожалению, но надеюсь, что скоро приобрету :)
Что не мешает использовать PostgreSQL в 1С, немало пользователей.
Я немножко не понял ваши возражения — а что, разве MySQL поддерживается 1С?
Я именно MySQL с PostgreSQL сравниваю.
Для PostgreSQL есть версия 1С, я нигде не утверждал, что она лучше MS SQL сервера — но она существует в природе, она используется.
Версии на базе MySQL не существует в природе.
Ровно это я хотел сказать, и ровно это и было сказано :)
Если я всё правильно понял из статьи, то там прямо говорится, что Бегун запилил свой libslave, занимающийся разбором бинлога, под свои узкопрофильные задачи, и что проверка консистентности данных проводится демоном потому что «Заметим, что на этапе первоначальной выборки данных их неконсистентность не говорит о том, что ошибки присутствуют в базе — просто это такая особенность процесса загрузки данных. Такая неконсистентность будет исправлена далее демоном при дочитывании данных. А вот если после этого в них есть какие-то несоответствия — тогда уже да, тогда это база.»
Вас удовлетворит, если я скажу, что все проблемы с целостностью данных которые встречались нам были связаны с ошибками приложения-писателя, и ни разу не было проблем, связанных с libslave?
Моя претензия к СУБД ровно в одном: из-за отсутствия CHECK мы не можем поймать такие ошибки на этапе записи, и нам приходится их ловить пост-фактум.
dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
Бажное(зарепорчено?)/не использовалось вообще/сливало данные в бинлог до проверки (зарепорчено?)?
Отсутствие table inheritance и constraint'ов общего вида — это не баг, а отсутствие функциональности.
Низкопроизводительный костыль, нет?
Как и любой инструмент — бывают задачи, где инструмент адекватен, бывают задачи, где неадекватен.
CHECK отсутствует, но легко реализуем через триггеры.
Остальные «constraint'ы общего вида» в MySQL присутствуют из коробки и вполне работоспособны.
dev.mysql.com/doc/refman/5.6/en/create-table.html
Простите, но «мой» порошок — это как раз MySQL.
Я над ним работал в Percona, занимался как раз репликацией.
Я с ним вожусь в Mail.Ru Target, постоянно, и помогаю коллегам.
PostgreSQL для меня знаком гораздо меньше, я в нём энтузиаст, а не серьёзный пользователь (мелкие личные проекты не в счёт).
И, к сожалению, я вынужден констатировать, что причин выбирать MySQL для новых проектов практически не осталось.
Хотя MySQL — мой хлеб.
Покажите, пожалуйста, мне систему, в который сделан и работает честный master-master.
Это миф. Нету таких. Или практически нету. Или до первого развала кластера или полной остановки при падении одного из узлов.
Я не специалист в 1С, но вы ТОЧНО уверен, что на терминалах стоит своя версия СУБД и что там мастер-мастер между терминалами и базой?
Насколько мне известно, база одна, а терминалы и все остальные — клиенты к ней.
Вангую, что это не проблема проверки ссылочной целостности на уровне БД (foreign key запретили что ли?), а проблема рассинхрона данных в БД и их копии в памяти, из-за которой и пришлось городить костыли. К выбору MySQL/PostgreSQL никакого отношения не имеющая. Поправьте меня, если ошибаюсь.
Проблема именно в том, что в MySQL вставляют некорректные данные, и в нём нету возможности запретить такие данные вставлять.
Мы обсуждали ссылочную целостность. Отсюда и контекст. При чём тут полнотекстовый поиск? Да и вообще для этих задач из опенсорса есть Solr/Elasticsearch/Sphinx. Всё остальное — зло.
Затем, что проекты сидящие на 5.5 часто используют одновременно MyISAM таблицы для полнотекстового поиска и InnoDB таблицы для всего остального. А между движками, увы, с транзациями все плохо, про constraint'ы я вообще молчу.
Начнём с того, что PostgreSQL изначально была Object-Relational DB. И её по фичам невозможно сравнивать с классической RDBMS.
Во-вторых, вопрос был в том, что именно из sql constraints (за исключением check) реализовано в PostgreSQL и отсутствует в MySQL или же реализовано «не достаточно»?
Я уже сказал что — constraint'ы общего вида, или «ограничения ссылочной целостности общего вида».
Это совершенно чёткий термин.
Например, тут описан: citforum.ru/database/advanced_intro/54.shtml
Да, тот самый пресловутый CHECK, без которого в сложных проектах жизнь становится горькой
Кластерные индексы — интересная тема. Да, в отдельных случаях они ускоряют запросы.
В PostgreSQL есть www.postgresql.org/docs/9.3/static/sql-cluster.html- не кластерные индексы, конечно, но позволяет достичь схожих результатов
И какое это имеет отношение к ссылочной целостности?
Демон работает как slave к MySQL и держит в памяти копию данных
Данные — рекламные кампании, баннеры, деньги на счету рекламодателей, и ещё кучу разных данных.
Он не может загрузить таргетинги, например, если в таргетингах кривая косвенная ссылка на баннер или кампанию — т.е. демон обнаруживает неконсистентность данных, и в такой ситуации рапортует о ней.
Демон был бы сильно проще, если бы эти проверки делала СУБД, и ДО вставки данных в базу, а не ПОСЛЕ
То что в InnoDB в данном контексте это очевидно, думаю
Совершенно неочевидно. До, кажется, 5.6 в InnoDB не было полнотекстового поиска, а в 5.6 уже есть регрессия производительности репликации, потому многие сидят на 5.5
Не очевидно, каких именно проверок ссылочной целостности не хватает в Мускуле для полного счастья?
Например, у нас в таблицах есть поля вида linked_object_type, linked_object_id — это называется table inheritance (между прочим, в postgresql он есть «из коробки», а в mysql его приходится эмулировать) — когда таблица связана не с одной таблицей, а с некоторых заданным множеством таблиц, некоторые такой полиморфизм на уровне таблиц.
Нам это нужно, это бизнес-требование.
Без поддержки table inheritance и constraint'ов общего вида проверять валидность таких ссылок можно лишь на уровне приложения, а это очень неудобно.
Из забытого в статье: благодаря хорошему журналу, у PostgreSQL полностью транзакционный DDL (data definition language) — т.е. можно в транзакциях менять схему данных, и эти изменения буду транзакционными.
MySQL о таком даже мечтать не смеет, к сожалению.
К сожалению, примерно так сейчас выглядит положение MySQL в сравнении с PostgreSQL.
Исключение — гиперогромные проекты, вроде Facebook, в которых MySQL (точнее, InnoDB) используется как B-Tree хранилище по ключу.
Но это очень специальный и очень особенный случай, на него не следует смотреть почти никогда.
К тому же, с появлением движка sophia в tarantool ситуация становится гораздо неоднозначней — не будет ли sophia лучше, чем MySQL?
На полном серьёзе. Один из наших демонов, работающий как slave к MySQL, мониторит ссылочную целостность (ему без неё слишком грустно) и выводит специальную админку, в которой показывает висячие ссылки.
Крайне печально, что приходится так с этим жить, но альтернатива — просто битая база и проблемы пользователей.
В PostgreSQL практически все наши хотелки описываются через constraints общего вида.
Microsoft Windows — ужасная платформа, а вот Microsoft SQL Server цены нет.
Прогресс — непрерывное поступательное движение вперёд.
И да, опыт использования для мелких проектов есть, функциональную часть я имел возможность оценить
Касательно нагруженных проектов — пока опыта нет, к сожалению, но надеюсь, что скоро приобрету :)
Я немножко не понял ваши возражения — а что, разве MySQL поддерживается 1С?
Я именно MySQL с PostgreSQL сравниваю.
Для PostgreSQL есть версия 1С, я нигде не утверждал, что она лучше MS SQL сервера — но она существует в природе, она используется.
Версии на базе MySQL не существует в природе.
Ровно это я хотел сказать, и ровно это и было сказано :)
Вас удовлетворит, если я скажу, что все проблемы с целостностью данных которые встречались нам были связаны с ошибками приложения-писателя, и ни разу не было проблем, связанных с libslave?
Моя претензия к СУБД ровно в одном: из-за отсутствия CHECK мы не можем поймать такие ошибки на этапе записи, и нам приходится их ловить пост-фактум.
Отсутствие table inheritance и constraint'ов общего вида — это не баг, а отсутствие функциональности.
Как и любой инструмент — бывают задачи, где инструмент адекватен, бывают задачи, где неадекватен.
Триггеры часто запрещены безопасниками.
Я над ним работал в Percona, занимался как раз репликацией.
Я с ним вожусь в Mail.Ru Target, постоянно, и помогаю коллегам.
PostgreSQL для меня знаком гораздо меньше, я в нём энтузиаст, а не серьёзный пользователь (мелкие личные проекты не в счёт).
И, к сожалению, я вынужден констатировать, что причин выбирать MySQL для новых проектов практически не осталось.
Хотя MySQL — мой хлеб.
Умеет. Называется BDR — bidirectional replication.
В этом сценарии нету репликации. Есть одна штука база, и к ней куча клиентов.
Для репликации нужно два сервера с базой данных и репликация между ними.
Я не говорил «тупой», я говорил «имеет меньше возможностей» и «практически не имеет оптимизатора».
Это миф. Нету таких. Или практически нету. Или до первого развала кластера или полной остановки при падении одного из узлов.
Я не специалист в 1С, но вы ТОЧНО уверен, что на терминалах стоит своя версия СУБД и что там мастер-мастер между терминалами и базой?
Насколько мне известно, база одна, а терминалы и все остальные — клиенты к ней.
Вы ошибаетесь. Подробней читайте тут: habrahabr.ru/company/mailru/blog/219015/
Проблема именно в том, что в MySQL вставляют некорректные данные, и в нём нету возможности запретить такие данные вставлять.
Затем, что проекты сидящие на 5.5 часто используют одновременно MyISAM таблицы для полнотекстового поиска и InnoDB таблицы для всего остального. А между движками, увы, с транзациями все плохо, про constraint'ы я вообще молчу.
Я уже сказал что — constraint'ы общего вида, или «ограничения ссылочной целостности общего вида».
Это совершенно чёткий термин.
Например, тут описан: citforum.ru/database/advanced_intro/54.shtml
Да, тот самый пресловутый CHECK, без которого в сложных проектах жизнь становится горькой
В PostgreSQL есть www.postgresql.org/docs/9.3/static/sql-cluster.html- не кластерные индексы, конечно, но позволяет достичь схожих результатов
Я лично практически не видел проектов, где действительно нужен мульти-мастер.
Демон работает как slave к MySQL и держит в памяти копию данных
Данные — рекламные кампании, баннеры, деньги на счету рекламодателей, и ещё кучу разных данных.
Он не может загрузить таргетинги, например, если в таргетингах кривая косвенная ссылка на баннер или кампанию — т.е. демон обнаруживает неконсистентность данных, и в такой ситуации рапортует о ней.
Демон был бы сильно проще, если бы эти проверки делала СУБД, и ДО вставки данных в базу, а не ПОСЛЕ
Совершенно неочевидно. До, кажется, 5.6 в InnoDB не было полнотекстового поиска, а в 5.6 уже есть регрессия производительности репликации, потому многие сидят на 5.5
Например, у нас в таблицах есть поля вида linked_object_type, linked_object_id — это называется table inheritance (между прочим, в postgresql он есть «из коробки», а в mysql его приходится эмулировать) — когда таблица связана не с одной таблицей, а с некоторых заданным множеством таблиц, некоторые такой полиморфизм на уровне таблиц.
Нам это нужно, это бизнес-требование.
Без поддержки table inheritance и constraint'ов общего вида проверять валидность таких ссылок можно лишь на уровне приложения, а это очень неудобно.
Демон подбирает баннеры рекламной системы Таргет
Да, пожалуй, так будет корректней выразиться
Не в MySQL, а в InnoDB. И таких базовых проверок явно недостаточно.
MySQL о таком даже мечтать не смеет, к сожалению.
Исключение — гиперогромные проекты, вроде Facebook, в которых MySQL (точнее, InnoDB) используется как B-Tree хранилище по ключу.
Но это очень специальный и очень особенный случай, на него не следует смотреть почти никогда.
К тому же, с появлением движка sophia в tarantool ситуация становится гораздо неоднозначней — не будет ли sophia лучше, чем MySQL?
Крайне печально, что приходится так с этим жить, но альтернатива — просто битая база и проблемы пользователей.
В PostgreSQL практически все наши хотелки описываются через constraints общего вида.