Pull to refresh

Comments 173

UFO just landed and posted this here
Странно, я ведь упомянул преимущества MySQL — более простое администрирование, как минимум…
Ну, к слову сказать, вы это выставили так, что если чуть перефразировать то получится примерно следующее-
«MySQL легче администрировать, потому что он тупой» :)
Я не знаю, что такое «тупой» в отношении СУБД.
Я не говорил «тупой», я говорил «имеет меньше возможностей» и «практически не имеет оптимизатора».
Просто вы поинтересовались у bitfroster, почему он не заметил плюсов MySQL в статье. Я их тоже не заметил, а указанный вами абзац на плюс не тянет.
Со словом «тупой» я может быть и переборщил :)
К сожалению, у MySQL в сравнении с PostgreSQL очень мало плюсов, и их становится всё меньше.
В таком случае заголовок статьи вводит читателя в заблуждение) Обычно в сравнении двух продуктов даются сильные и слабые стороны как одного, так и второго.
А здесь, как верно заметил автор ветки — все как в рекламе порошка) Сравним обычный и наш, наш делает все, а ваш просто стирает :)
Простите, но «мой» порошок — это как раз MySQL.
Я над ним работал в Percona, занимался как раз репликацией.
Я с ним вожусь в Mail.Ru Target, постоянно, и помогаю коллегам.

PostgreSQL для меня знаком гораздо меньше, я в нём энтузиаст, а не серьёзный пользователь (мелкие личные проекты не в счёт).

И, к сожалению, я вынужден констатировать, что причин выбирать MySQL для новых проектов практически не осталось.
Хотя MySQL — мой хлеб.
Это не очень конструктивный диалог, который ничем хорошим не закончится. Давайте остановимся и разойдемся чай пить :)
UFO just landed and posted this here
Только вот этих молодых разработчиков потом, в любых проектах связанных с DB и крупнее, чем «сайт визитка на одной страничке с гостевой книгой» приходится брать на любые должности, максимально удалённые от DBA, из-за того, что MySQL у них из головы уже ничем не выбить.

Как показывает практика, на этапах подготовки DBA, архитектора баз данных или программиста в проекте с DB, гораздо лучше взять человека не знакомого с базами данных и обучить его работе с DB с нуля на примере PostgreSQL, Oracle или (прости господи) MSSQL, чем взять кого-то, кто уже начал знакомство с базами данных на примере mysql и его клонов.
Это зависит от того кого берете. Бывают кадры не хотят учится +Х лет определенных технологий
Совершенно верно. Просто по опыту заметил, что нежелание учится чему-то другому после mysql возникает гораздо раньше, чем накопится +X лет опыта работы с технологиями. Причина этого в тексте обозначена — mysql слишком не любит следовать общим стандартам.
А чем вас MS SQL пугает так? Приличная СУБД с широким функционалом. Я, в принципе, одинаково хорошо отношусь ко всем трём. Оракл совсем молодец но стоит просто адски за ядро, но поначалу можно мило поиграться с экспрессом и набить навыки. МС подешевше, умеет почти все тоже самое (в моей внутренней иерархии PL SQL занимает более высокое положение чем обычный SQL) + маркетинговые фишки типа БИ. Ну и слон который не стоит ничего, но при должной дрессировке умеет все (Отбросим AG и прочие дорогие штуки, нахаляву такого не бывает).
В общем ИМХО все молодцы и никакого ужас-ужас тут нет.
А MySQL регулярно вижу в связках с пхп. Логика на пхп, данные в мускуле. Когда спрашиваешь у разработчика зачем так было делать, в ответ лишь молчание, а в пустых глазах можно увидеть лишь одинокий нейрон бессильно бьющийся о теменную кость.
Справедливости ради, когда VPS давно сравнялся по цене с виртуальным хостингом, это уже выглядит как проблемы типовых хостингов, а не проблемы для пользователей.

Кстати, в WordPress поддержка Postgres подключается всего лишь плагином. Что бы что-то подобное реализовать в движке, который будет ориентироваться на возможности Postgres, придётся с нуля переписать движок для MySQL.

Одни только каскадные триггеры золотого стоят. А GIST/GIN индексы, hstore, а теперь ещё и подключилась тяжёлая артиллерия JSONB — сама мысль поддерживать совместимость с MySQL доставляет страдания.
Я с ним вожусь в Mail.Ru Target

Прочитал сначала как «Я с ним вожусь в Mail.Ru Agent» и уже хотел завести диалог на эту тему, но для достоверности всё же перечитал.
Более просто администрирование? Ты издеваешься да? :) Сейчас репликация в PostgreSQL настраивается проще чем в MySQL. Так-как PostgreSQL позволяет взять и отреплицировать живую базу штатной тулзой, а MySQL нет. Приходится использовать LVM.
По поводу баз много всего есть везде =)

Если вкратце о выборе нужно начинать с простых вопросов
1) Объем данных сколько их ТБ или ГБ
2) Как часто данные меняются? (или это read only)

дальше идут пункты по порядку наверное что были в статье
«Например, в MySQL приходится писать собственные инструменты для верификации обычной ссылочной целостности базы.»
Вы это серьёзно?
На полном серьёзе. Один из наших демонов, работающий как slave к MySQL, мониторит ссылочную целостность (ему без неё слишком грустно) и выводит специальную админку, в которой показывает висячие ссылки.

Крайне печально, что приходится так с этим жить, но альтернатива — просто битая база и проблемы пользователей.

В PostgreSQL практически все наши хотелки описываются через constraints общего вида.
Один из наших демонов, работающий как slave к MySQL, мониторит ссылочную целостность

Можно чуть подробнее, что именно делает ваш демон?

В PostgreSQL практически все наши хотелки описываются через constraints общего вида.

Если речь идёт о CHECK, то это проверка не ссылочной целостности, а данных. При желании отлично решается через триггеры.
Всё остальное (not null, unique, foreign keys) реализовано в MySQL в рамках стандарта SQL-92.
Можно чуть подробнее, что именно делает ваш демон?

Демон подбирает баннеры рекламной системы Таргет

Если речь идёт о CHECK, то это проверка не ссылочной целостности, а данных.

Да, пожалуй, так будет корректней выразиться

Всё остальное (not null, unique, foreign keys) реализовано в MySQL в рамках стандарта SQL-92.

Не в MySQL, а в InnoDB. И таких базовых проверок явно недостаточно.
Демон подбирает баннеры рекламной системы Таргет

И какое это имеет отношение к ссылочной целостности?

Не в MySQL, а в InnoDB. И таких базовых проверок явно недостаточно.

То что в InnoDB в данном контексте это очевидно, думаю.
Не очевидно, каких именно проверок ссылочной целостности не хватает в Мускуле для полного счастья?
И какое это имеет отношение к ссылочной целостности?

Демон работает как slave к MySQL и держит в памяти копию данных
Данные — рекламные кампании, баннеры, деньги на счету рекламодателей, и ещё кучу разных данных.
Он не может загрузить таргетинги, например, если в таргетингах кривая косвенная ссылка на баннер или кампанию — т.е. демон обнаруживает неконсистентность данных, и в такой ситуации рапортует о ней.

Демон был бы сильно проще, если бы эти проверки делала СУБД, и ДО вставки данных в базу, а не ПОСЛЕ

То что в InnoDB в данном контексте это очевидно, думаю

Совершенно неочевидно. До, кажется, 5.6 в InnoDB не было полнотекстового поиска, а в 5.6 уже есть регрессия производительности репликации, потому многие сидят на 5.5

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

Например, у нас в таблицах есть поля вида linked_object_type, linked_object_id — это называется table inheritance (между прочим, в postgresql он есть «из коробки», а в mysql его приходится эмулировать) — когда таблица связана не с одной таблицей, а с некоторых заданным множеством таблиц, некоторые такой полиморфизм на уровне таблиц.
Нам это нужно, это бизнес-требование.

Без поддержки table inheritance и constraint'ов общего вида проверять валидность таких ссылок можно лишь на уровне приложения, а это очень неудобно.
Он не может загрузить таргетинги, например, если в таргетингах кривая косвенная ссылка на баннер или кампанию — т.е. демон обнаруживает неконсистентность данных, и в такой ситуации рапортует о ней.

Вангую, что это не проблема проверки ссылочной целостности на уровне БД (foreign key запретили что ли?), а проблема рассинхрона данных в БД и их копии в памяти, из-за которой и пришлось городить костыли. К выбору MySQL/PostgreSQL никакого отношения не имеющая. Поправьте меня, если ошибаюсь.

Совершенно неочевидно. До, кажется, 5.6 в InnoDB не было полнотекстового поиска, а в 5.6 уже есть регрессия производительности репликации, потому многие сидят на 5.5

Мы обсуждали ссылочную целостность. Отсюда и контекст. При чём тут полнотекстовый поиск? Да и вообще для этих задач из опенсорса есть Solr/Elasticsearch/Sphinx. Всё остальное — зло.

Без поддержки table inheritance и constraint'ов общего вида проверять валидность таких ссылок можно лишь на уровне приложения, а это очень неудобно.

Начнём с того, что PostgreSQL изначально была Object-Relational DB. И её по фичам невозможно сравнивать с классической RDBMS.
Во-вторых, вопрос был в том, что именно из sql constraints (за исключением check) реализовано в PostgreSQL и отсутствует в MySQL или же реализовано «не достаточно»?
Вангую, что это не проблема проверки ссылочной целостности на уровне БД (foreign key запретили что ли?), а проблема рассинхрона данных в БД и их копии в памяти, из-за которой и пришлось городить костыли. К выбору MySQL/PostgreSQL никакого отношения не имеющая. Поправьте меня, если ошибаюсь.

Вы ошибаетесь. Подробней читайте тут: habrahabr.ru/company/mailru/blog/219015/

Проблема именно в том, что в 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, без которого в сложных проектах жизнь становится горькой
Вы ошибаетесь. Подробней читайте тут: habrahabr.ru/company/mailru/blog/219015/

Если я всё правильно понял из статьи, то там прямо говорится, что Бегун запилил свой libslave, занимающийся разбором бинлога, под свои узкопрофильные задачи, и что проверка консистентности данных проводится демоном потому что «Заметим, что на этапе первоначальной выборки данных их неконсистентность не говорит о том, что ошибки присутствуют в базе — просто это такая особенность процесса загрузки данных. Такая неконсистентность будет исправлена далее демоном при дочитывании данных. А вот если после этого в них есть какие-то несоответствия — тогда уже да, тогда это база.»

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

dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
Бажное(зарепорчено?)/не использовалось вообще/сливало данные в бинлог до проверки (зарепорчено?)?

Затем, что проекты сидящие на 5.5 часто используют одновременно MyISAM таблицы для полнотекстового поиска и InnoDB таблицы для всего остального.

Низкопроизводительный костыль, нет?

Да, тот самый пресловутый CHECK, без которого в сложных проектах жизнь становится горькой

CHECK отсутствует, но легко реализуем через триггеры.
Остальные «constraint'ы общего вида» в MySQL присутствуют из коробки и вполне работоспособны.
dev.mysql.com/doc/refman/5.6/en/create-table.html
Если я всё правильно понял из статьи, то там прямо говорится, что Бегун запилил свой 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

Триггеры часто запрещены безопасниками.
Байка про foreign keys в MySQL: иногда данные по каким-то причинам нельзя стереть. Falls и ни туды ни сюды.
Зато можно переименовать таблицу, удалить не нужное, и переименовать обратно.
И ключики поднимутся и все будет как раньше… Мистика.
Вас удовлетворит, если я скажу, что все проблемы с целостностью данных которые встречались нам были связаны с ошибками приложения-писателя, и ни разу не было проблем, связанных с libslave?

Ну тут не в удовлетворении дело… :) Меня просто интересуют сложные ситуации на продакшене. Вот и докапываюсь, откуда ноги растут, наступившие и победившие грабли.
По поводу CHECK я понял. Хоть это и не имеет отношения конкретно к ссылочной целостности, но мы точки на i расставили. Спасибо.
Ну тут не в удовлетворении дело… :) Меня просто интересуют сложные ситуации на продакшене. Вот и докапываюсь, откуда ноги растут, наступившие и победившие грабли.

Печально, что вы меня почти не слушали, и вместо попыток понять пытались мне объяснить, что я ошибся

По поводу CHECK я понял. Хоть это и не имеет отношения конкретно к ссылочной целостности, но мы точки на i расставили. Спасибо.

Конечно, имеет. table inheritance для поддержания ссылочной целостности требует CHECK, а его нет.
Триггеры часто запрещены безопасниками.

Ух, а можно узнать почему? В своем проектике активно использую, например для updated_at, какие могут быть проблемы?
Какой-то не многословный этот Том…
Triggers are so abused — and used so inappropriately, I'd rather live without them.

Аргументов я не увидел, ну возможно кто-то злоупотребляет, есть вещи которые невозможно или почти невозможно сделать без триггеров без переноса логики в приложение.
В комментах он говорит подробней.
Берете две таблицы. Одну делаете в MyISAM, а вторую в InnoDB. А теперь попробуйте сделать foreign key банальный.
Я в курсе. Но фигни это никак не отменяет.
Фигня — это предлагать сделать foreign key на двигле, который foreign key не поддерживает и говорить при этом «фигня» )))
Фигня это РСУБД не поддерживающая foreign key :]
«Фигня» — это использование MyISAM в 2015м году.
К сожалению, примерно так сейчас выглядит положение MySQL в сравнении с PostgreSQL.
Исключение — гиперогромные проекты, вроде Facebook, в которых MySQL (точнее, InnoDB) используется как B-Tree хранилище по ключу.

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

К тому же, с появлением движка sophia в tarantool ситуация становится гораздо неоднозначней — не будет ли sophia лучше, чем MySQL?
Исключение — гиперогромные проекты, вроде Facebook, в которых MySQL (точнее, InnoDB) используется как B-Tree хранилище по ключу.


Мне кажется для этого наверное лучше было бы использовать тот же Redis?
И использование MySQL тут чисто историческое?
При чем тут Redis? В Редисе нет деревьев. В тоже время, я очень сомневаюсь, что фейсбук использует MySQL только для того, чтобы костыльно и с огромным оверхедом на ненужные вещи получить доступ к структуре данных, которая пишется за неделю и занимает тысячу строк кода. И более того, она у них уже написана и называется RocksDB.
B-Tree хранилище по ключу

Слово «ключ» меня смутило. Мне показалось, что они B-Tree деревья по ключу хранят.
Хотя вот сейчас полез проверять и не нашел 100% подтверждения, что в RocksDB b-tree, в код лезть пока лень, но на всякий случай не полагайтесь на это мое заявление.
Смотрите мой комментарий ниже про B-Tree
которая пишется за неделю и занимает тысячу строк кода

Это неправда. Задам два простых вопроса: насколько консервативен алгоритм объединения страниц в вашей версии «на тысячу строчек кода» и как у вас дела c Point-In-Time-Recovery?

Давайте я просто покажу вам метрики из InnoDB
oleg@x200:~/mrg/mysql-5.5.39/storage/innobase
➜ sloccount {btr,page}/* 2>&1 | grep ansic
14506 top_dir ansic=14506
ansic: 14506 (100.00%)


15 тысяч строчек кода. Это без блокировок, транзакций и журнала. Просто B-Tree дерево.
MySQL 5.5.39
Я сам реализовывал B-tree и знаю, что это алгоритм не на 15 тысяч строк и близко. В InnoDB оно может столько занимать потому, что старается быть пуленепробиваемо надежным, с точки зрения любых ошибок и отказа питания в любой момент времени. Я не говорю, что это плохо, но это очень дорого. В принципе, если это именно то, что нужно Фейсбуку, то на остальной оверхед можно подзабить, по сравнению с тем количеством disk IO, которое надо сделать при каждом обновлении таблицы. Тогда да, взять готовый код, жертвуя относительно небольшим дополнительным оверхедом выглядит разумно.
Боюсь, вы не понимаете всей проблематики и просто не тестировали ваш код под серьёзной нагрузкой — потому и не столкнулись с проблемами.
Я делал чисто академическую реализацию алгоритма B-tree. На database scale могут быть проблемы другого уровня сложности — спорить не буду.
Оставлю тут пруфы для будущих поколений (2010 год, но концептуально врядли что-то поменялось):

We use MySQL primarily as very reliable way of storing bits on disk… We use it as a key-value system deployed across thousands of machines.

www.infoq.com/presentations/Scale-at-Facebook (30:50)
На конференции HighLoad частенько появляются личности из FaceBook. Их можно пораспрашивать как они допиливали напильниками и обстукивали «барсиками» MySQL чтобы он нормально работал. В процессе желательно поить коньяком. Можно нарваться на вспышки неконтролируемой агрессии.
Из забытого в статье: благодаря хорошему журналу, у PostgreSQL полностью транзакционный DDL (data definition language) — т.е. можно в транзакциях менять схему данных, и эти изменения буду транзакционными.
MySQL о таком даже мечтать не смеет, к сожалению.
Всегда было интересно как в проектах на mysql без этого работают миграции?
Мучительно. С остановкой записи, либо через триггеры (при помощи percona-toolkit)
Это Вы сейчас хотите сказать, что постгрес не останавливает запись при альтерах на таблицы?
Зависит от конкретного альтера, но чаще нет, чем да.
Так там даже проблема не в том что запись надо останавливать а в том что миграция в середине внезапно по причине кривых рук программиста зафейлилась и все. Ни вперед ни назад не перемотать.
Это вообще боль. Ещё внезапно у Oracle нетранзакционный DDL. После Postgres как ушат ледяной воды на голову.
Интересно, а мульти-мастер репликацию от Galare в Percona кластере кто-нибудь недавно тестировал под нагрузкой? Поделиться опытом…
Это семисинхронная репликация, со всеми плюсами и минусами.
Я лично практически не видел проектов, где действительно нужен мульти-мастер.
Это по крайней мере очень удобно. Например мы используем Cassandra и я прям не могу нарадоваться тому что не надо думать где мастер, где слейв, что будет если ляжет мастер или вообще произойдет split brain.
На многих гос-проектах всегда требуют сделать защиту от потери данных, если с ЦОДом что-то случится и синхронная репликация, даже не обязательно мульти-мастер, оч. проста и удобна. Это конечно глупо гонять данные на другой ЦОД и ждать ответа, но если по нагрузке проблем нет, то юзать можно.
Используем.

Плюсы:
— простая процедура ввода новых нод
— никаких телодвижений при выходе из строя какой-либо ноды (главное, чтобы рабочих было не менее трех)

Минусы:
— приложение нужно учить писать только в одну ноду, иначе под нагрузкой вы столкнетесь с банальной потерей записей.

Как по Вашему, является ли серьезным недостатком PostgreSQL отсутствие кластерных индексов?
На этом сайте написано что они есть в планах. Не знаете случайно, как долго ждать?)
Кластерные индексы — интересная тема. Да, в отдельных случаях они ускоряют запросы.
В PostgreSQL есть www.postgresql.org/docs/9.3/static/sql-cluster.html- не кластерные индексы, конечно, но позволяет достичь схожих результатов
Этот самый «кластерный индекс» в постгресе не поддерживает обновления данных и на практике портит оптимизатора запросов (некоторые запросы вместо работы по индексам делают full table scan). То есть фактически его нет.

При этом с MySQL в условиях, когда памяти сильно меньше горячих данных, только кластерный индекс спасает производительность хоть сколько-то больших выборок по диапазону в primary key. Это реальный кейс многих высоконагруженных проектов, и в них постгрес непригоден. По мелочи, бывает полезно, что в InnoDB primary индекс содержит данные.

С другой стороны, на мой взгляд, на этом исчерпываются ключевые преимущества MySQL перед Postgres. Впрочем, говорят, репликация в mysql гораздо более адекватная (благодаря galera), и актеры
«кластерный индекс» — это как попытка выйграть на спичках при кешировании строк страницами хранилища
Большая тема, давно думаем над этим. Существующий принцип хранения данных в постгресе (плоский heap + индексы ссылающиеся на физическую позицию в heap) не очень сочетается с кластерными индексами. По-идее нужно идти в сторону pluggable storage engines, как их лучше реализовать. Опять же, путь MySQL, когда storage enigne это почти пол-СУБД, чреват тем, что не будет достаточно ресурсов их все поддерживать. Поэтому думаем в сторону какого-то компромиссного варианта.
А материализованные представления используют тот же принцип хранения?
Мне кажется было бы интересно держать таблицу в привычном виде, и иметь возможность создавать к ней несколько автообновляемых кластеризованных материальных представлений. Хотя может я думаю не в том направлении)
Да, матвьюхи хранятся так же, как и таблицы. На матвьюхах можно получить те же преимущества, которые даёт команда CLUSTER просто указав в порождающем запросе ORDER BY. Но есть вопрос к обновлению матвьюх, пока что они у нас рефрешатся вручную. Автоматическое обновление только в планах. Но даже если оно будет, то оно будет нарушать упорядоченность данных в таблице, подобно тому как сейчас DML операторы постепенно нарушают результат команда CLUSTER.
Раз уж затронули 1с, спрошу: способен ли PostgreSQL реализовать честный master-master и горизонтально масштабироваться добавлением серверов с БД?

Т.е. есть, скажем, кластер терминалов с серверной частью 1С на каждом + несколько серверов постгреса с мастер-мастер к которым обращаются терминалки?
Покажите, пожалуйста, мне систему, в который сделан и работает честный master-master.
Это миф. Нету таких. Или практически нету. Или до первого развала кластера или полной остановки при падении одного из узлов.

Я не специалист в 1С, но вы ТОЧНО уверен, что на терминалах стоит своя версия СУБД и что там мастер-мастер между терминалами и базой?
Насколько мне известно, база одна, а терминалы и все остальные — клиенты к ней.
Автор статьи рассказывает какая шикарная репликация в PostgreSQL, я спрашиваю как её применять на практике в очень востребованном кейсе.

Одна БД + пачка терминалов это просто.
Одна БД + пачка терминалов это просто.

В этом сценарии нету репликации. Есть одна штука база, и к ней куча клиентов.

Для репликации нужно два сервера с базой данных и репликация между ними.
Спасибо, я знаю что нужно более одного сервера.
Так как сделать мастер-мастер для 1С на PostgreSQL?

image

Если PostgreSQL не умеет так, что он может предложить для масштабирования 1С?
Если PostgreSQL не умеет так, что он может предложить для масштабирования 1С?

Умеет. Называется BDR — bidirectional replication.
BDR который available for immediate end-user deployment as a small patch on top of PostgreSQL 9.4 plus an extension module?

В то время как последняя стабильная версия для 1С это 9.2.1?
Что не мешает использовать PostgreSQL в 1С, немало пользователей.

Я немножко не понял ваши возражения — а что, разве MySQL поддерживается 1С?
Я именно MySQL с PostgreSQL сравниваю.
Для PostgreSQL есть версия 1С, я нигде не утверждал, что она лучше MS SQL сервера — но она существует в природе, она используется.
Версии на базе MySQL не существует в природе.

Ровно это я хотел сказать, и ровно это и было сказано :)
Будем говорить прямо: та поддержка PostgreSQL, которая есть на данный момент в 1C, по-сути своей является экспериментальной. То, что она в таком состоянии зависла на много лет – другой вопрос. Но выдам небольшой обнадёживающий инсайд: 1С собирается скоро исправиться в этом плане. Производительность вырастет и геммороя станет значительно меньше.
1С наконец то будет работать с родным PgSQL? Или все также только с патченой версии с сайта?
С родным, на который установлен 1Совский extension.
Яростно плюсую!
Они наконец забудут эту тему с case-insensitive?
Поддержу: мультимастер на РСУБД, только если синхронный. Иначе возможна потеря целостности и транзакционности. Ту же транзакционность обеспечивает какой либо GlobalTransactionManager.
А асинхронный мультимастер на связанных данных — в общем случае просто невозможен (хотя в принципе можно придумать асинхронную мультимастерность путем связного партиционирования связанных данны, но это очень частный случай). И как после брейнсплита востанавливаться после транзакций?
Из больших преимуществ PostgreSQL лично для меня:

  1. JSONB — позволяет убрать пару сотен каких-то тухлых колонок (в 90% случаев NULL) схлопнув их в одну-две по смыслу и при этом иметь возможность эффективного поиска по ним в случае необходимости (индексы там наложить)
  2. Range Types — никаких больше колонок planned_worktime_start и planned_worktime_end и пляски с операторами сравнения для нахождения других строк, у которых интервал, задаваемый этими колонками пересекается с этой строков. Всё необходимое уже есть (включая constraints, про которые обещали рассказать в соседнем топике).
  3. Прочие нативные типы: interval, cidr и другие, со встроенными методами работы с ними.
  4. Массивы — жуткое нарушение 1-й нормальной формы, но когда всё, что необходимо — это сохранить несколько строчек, то горождение отдельной таблицы с перспективой JOIN'а с ней выглядит совсем непривлекательно.
  5. И самое главное — то, что наш инструмент поддерживает всё это из коробки. А мы работаем на Ruby on Rails. А рельсы ну просто обожают PostgreSQL. JSONB превращается в объект типа Hash, tsrange превращается в объект типа Range с границами в виде объектов DateTime, массив становится массивом. И обратно! Это просто возмутительно прекрасно! MySQL такой любви со стороны разработчиков фреймворка почему-то не испытывает.
>Массивы — жуткое нарушение 1-й нормальной формы

Это далеко не всегда так, и Дейт об этом пишет. С первой нормальной формой все не так однозначно. Даже значения-реляции вполне допустимы в реляционной модели, массив лишь их частный случай.
жуткое нарушение 1-й нормальной формы

И ещё огромный буст к производительности, если использовать GIST индекс.
т.е. у меня на сайте постоянная задача искать по тегам (есть картинка и у неё до сотен тегов, а картинок под пол-ляма), так вот GIST по array позволяет ускорить поиск в 10-20 раз. Даже если сравнивать не с many-to-many а с одним JOIN (для ускорения, я сначала находил id тегов, и потом уже делал тупо join с промежуточной таблицей).
+ ещё на днях познакомился с NOTIFY/LISTEN. Очень прикольная фича, которая может внезапно выручить.
Я тут удивился. Вы правда считаете Microsoft SQL — фантастической СУБД? Можно поинтересоваться в чем она является фантастической?
Например, офигенный оптимизатор: citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.98.9460 богатые типы данных, очень классные интерактивные инструменты анализа производительности, широкая поддержка стандартов

Microsoft Windows — ужасная платформа, а вот Microsoft SQL Server цены нет.
В плане анализа и оптимизатора, имхо, оракл по-прежнему лидер.
Вы не поверите, в Oracle тот же самый алгоритм — Cascades
Я бы с радостью протестировал высоконагруженный сервер MSSQL и его скопированный с Oracle механизм оптимизатора (который в Oracle, если я ничего не путаю появился лет на 10 раньше) на архитектуре IBM Power или на PC архитектуре под *nix, но к сожалению, не могу этого сделать, потому как MSSQL не предоставляет возможности выбора платформы. А хороших серверов DB на плохих платформах (если брать вашу оценку) не бывает, по определению.
Но в итоге, эта связка очень медленная. Вот если бы MS SQL работал не только на Windows тогда бы можно было бы не перекладывать «особенности» Windows на MS SQL, а так это жутко.
UFO just landed and posted this here
UFO just landed and posted this here
а теперь попробуйте не простенькие запросы :) для аналитики mysql и postgresql, например, слабо подходят
А если учесть наличие оконных функций?
На больших объемах (больше 1Тб) уже не помогает. Мы после постгри перешли на hp vertica.
А потом захотел сделать выборку по индексу из двух полей (например код ответа и дата, которые используется для сортировки) — а хрен там, Archive такое не поддерживает, приходится ставить индекс только на одно поле (код ответа) и получать почти full scan.
Я помню лет 10 назад в MySQL появилась первая репликация. Сделана она была через пересылку SQL запроса на соседний сервер. После этого я забыл про MySQL.
10 лет прошло, а я смотрю ничего и не изменилось.
Я понял, какой правильный ответ на твой пост, Олег :). А ответ такой: ждем такого же поста с разжевыванием недостатков PostgreSQL через несколько лет :).

Ибо MySQL пользуются почти все и его недостатки хорошо изучены и известны. А PostgreSQL ты даже сам особо не пробовал, так что твои рассуждения — это какая-то теория, без применения к практике.
Сообщение в ключе «я не хочу слезать со своей отсталой технологии», извиняюсб, не сдержался
Не могу согласиться с утверждением, что MySQL «отсталая технология» по сравнению с продуктом X (не важно, что сюда подставлять, PostgreSQL, Tarantool, etc...). У MySQL есть своя ниша — «в идеале» это веб-сервера. То есть, MySQL очень прост в настройки и неприхотлив в эксплуатации, и умеет примерно ничего сверхсложного, зато умеет это быстро и достаточно надежно при условии использования InnoDB. В основном MySQL заточен на максимальную производительность простых запросов и в меньшей степени на то, чтобы эффективно исполнять запросы сложные. То, что Олег вообще использует statement-based однопоточную репликацию в мускуле и она еле справляется — это скорее проблема неверно выбранного инструмента именно для этой задачи.
В основном MySQL заточен на максимальную производительность простых запросов и в меньшей степени на то, чтобы эффективно исполнять запросы сложные

Ну а что такое простые запросы? Селект по праймари кею, т.е. мускуль с иннодиби умеет это делать значительно лучше не только постгреса (что не очень важно), но и редиса и т.д.?

Иначе, какой смысл использовать продукт А, ежели он обрезанная версия продукта Б, за те же деньги?
Часто бывает важно в вебе:

1) дешевый коннект
2) запросы по PK как на SQL, так и на HandlerSocket-слоях очень быстрые
3) запросы с выборкой по индексу с лимитом и ордер бай
4) простенькие группировки по индексированным полям

Иногда бывает полезно:
1) очень быстрый фулл скан таблиц (MyISAM), с возможностью писать/читать напрямую в дата-файлы, что дает еще 5-ти кратный прирост скорости (таблица на 1 млн строк и размером 30 Мб сканируется за 15 мс)
2) очень компактное хранение данных в MyISAM и надежное при условии append-only

Примеров больше, но это вроде бы основное :)
Есть ощущение что вы используете реляционную субд как любой другой nosql K-V.

В статье как раз мнение, что постгрес это нечто интересней и сложней.
У меня из статьи и комментариев сложилось ощущение, что использовать реляционную субд как nosql K-V — это:
  1. нередко актуально
  2. одна из тех областей, где MySQL выглядит наиболее выигрышно на фоне PostgreSQL

А так — да, PostgreSQL интересней и сложней.
Key-Value, где вы его увидели в MySQL?
InnoDB — изначально K-V, а всё остальное уже поверх.
Есть несколько реализаций NoSQL протокола для InnoDB, позволяющие добиться повышения производительности на порядок за счёт существенного урезания функциональности.

Но смысл ведь не во внутренней структуре, а в коробочном наборе инструментов, которые доступны разработчику.
Смысл именно во внутренней структуре, поскольку иначе — хороших результатов не добиться никакими инструментами, доступными разработчику. А если разработчику связать руки, то можно долго вздыхать, что дело не делается.
1) дешевый коннект

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

очень быстрый фулл скан таблиц

Postgres вполне можно настроить на это (он адаптируется в зависимости от задачи).

очень компактное хранение данных

В posttgres так же всё достаточно компактно, а главное нету проблемы с «append-only». :)
1. Ну и pgbouncer ещё же есть
Много чего есть, тот же pgpool. Но это надо отдельно подымать.
Ну т.е. претензия только в том, что сама постгря не предоставляет это из коробки, а не в том, что решения не существует.
Главное решение, это не использовать PHP. :)
С удовольствием!
Прогресс — непрерывное поступательное движение вперёд.

И да, опыт использования для мелких проектов есть, функциональную часть я имел возможность оценить
Касательно нагруженных проектов — пока опыта нет, к сожалению, но надеюсь, что скоро приобрету :)
Касательно нагруженных проектов — пока опыта нет, к сожалению, но надеюсь, что скоро приобрету

Тогда самое интересное у вас еще впереди :)
Не совсем согласен с автором по поводу пункта «Документация». Точнее как — быть может документация на сайте MySQL и правда уступает документации PostgreSQL (хотя это весьма спорное утверждение), но вот в принципе в интернетах информационных ресурсов по MySQL в десятки раз больше чем по PostgreSQL. Взять хотя бы stackoverflow — 298,085 тредов против 35,063.

Ещё не указан один из весомейших на мой взгляд плюсов PostgreSQL — это PL/SQL. В MySQL-е с этим все очень и очень плохо, и сами разработчики не стесняются признаваться в этом. К этому же пункту можно отнести специализированные геоиндексы, JSONB и т.п.

И отсюда по-моему не совсем правильный вывод в финале статьи. Я бы сказал так — если вы точно, знаете, что собираетесь использовать все эти специализированные фичи (в особенности PL/SQL), то выбор в пользу PostgreSQL — однозначен. В остальных случаях — выбор в пользу того, с какой из БД больше всего знакома команда. И про «серьезные амбиции» и «большой проект» — считаю вообще не аргумент. Опыт таких гигантов как Google, Facebook, VK, twitter, badoo показал, что на MySQL можно более чем успешно разрабатывать вполне себе «большие проекты».

P.S. К слову, коль в статье была упомянута percona с их собственными тулами, то помимо их решений так же есть весьма неплохие патчи от Google code.google.com/p/google-mysql/.
Взять хотя бы stackoverflow — 298,085 тредов против 35,063.
Мне кажется это не показатель. Во всяком случае не однозначный показатель со смыслом «больше — лучше».

Сравнение количества вопросов по двум технологиям А (по которой вопросов больше) и Б (по которой вопросов меньше) на SO всегда можно обосновать кучей противоречивых причин:
1) А просто популярнее Б и имеет большее комьюнити
2) У А более активное и дружественное комьюнити
3) У А плохая документация
4) В А гораздо проще сделать неочевидную ошибку, которая требует помощи извне
5) У Б комьюнити и более опытных разработчиков, которые лучше умеют самостоятельно решить проблему (на основе документации, кода, опыта) и потому не задают простых вопросов
6) Официальные ресурсы А предлагают задавать вопросы именно на SO (а не, например, форуме технологии А)


В общем, вариантов много, а правды нет )
Опыт таких гигантов как Google, Facebook, VK, twitter, badoo показал, что на MySQL можно более чем успешно разрабатывать вполне себе «большие проекты».

Построить можно, но насколько это удобно? Почти все эти гиганты перепиливали mysql в доль и поперёк. VK так вообще очень специфично MySQL использует. А стали они юзать mysql так как в тот момент это было достаточно хорошее свободное решение, а у postgres было много болячек и недостатков. С начала 2000x много всего поменялось.
Гиганты, в своей области, правы. Все красивости PostgreSQL «из коробки» типа репликации и транзакций для них только минус: всё равно а) работают, и всегда будут работать, несколько не так как они хотят, и б) у них есть ресурсы чтоб реализовать то, что им надо из этого списка, самим. Поэтому берут InnoDB (в виде MySQL) и «обвешивают» сами чем им надо. Да, несколько напоминает «фатальный недостаток: not invented here», но тут это, по-моему, как раз из серии «гиганты могут себе позволить».
Ох, еще бы pgAdmin (особенно под никсы) был таким же прекрасным как сам Постгрес :)
А в чём проблема?
Исходники есть. В популярных дистрибутивах идёт в репозиториях.
К примеру, Archlinux:

[desktop] ~ $ yaourt -Si pgadmin3
Репозиторий           : community
Название              : pgadmin3
Версия                : 1.20.0-1
Описание              : Comprehensive design and management interface for PostgreSQL
Архитектура           : x86_64
URL                   : http://www.pgadmin.org
Лицензии              : custom
Группы                : Нет
Предоставляет         : Нет
Зависит от            : wxgtk2.8  postgresql-libs  libxslt
Дополнительно         : Нет
Конфликтует с         : Нет
Заменяет              : Нет
Будет загружено :   2,82 MiB
Установленный размер:  13,63 MiB
Сборщик               : Sergej Pupykin <pupykin.s+arch@gmail.com>
Дата сборки           : Чт 25 дек 2014 20:49:50
Проверен : MD5  SHA256  Подпись

Не сочтите за рекламу, но 0xDBE наше все :)
Ну, в целом он весьма неплох и на *nix и на OS X. Ему бы GUI только немного причесать, по моему мнению. А что вас не устраивает?
О да, про него разработчики постоянно забывают.
Ох эти мерцания диалоговых окон…
Кстати, во многом именно из-за pgAdmin, PostgreSQL воспринимается как динозавр
Оффтоп-вопрос пользователеям PostgreSQL.

Какое-то время назад смотрели возможность настроить Master-Slave репликацию, что бы с каких-то Slave'ов можно было в realtime производить чтения и тем самым разгрузить master'a. После чтения документации остановились на потоковой репликации
( www.postgresql.org/docs/9.1/static/warm-standby.html#STREAMING-REPLICATION )

Может быть выбор не самый лучший и можете посоветовать что-либо более подходящее для read-only slave'ов в PostgreSQL?
А нет ощущения, что MySQL вы широко используете в продакшене, и поэтому на его грабли натыкаетесь постоянно, а PostgreSQL — нет, и поэтому его грабли вы просто еще не знаете?
Ну, коллеги в мыле используют, с ними постоянно общаемся.
У PostgreSQL проблемы есть, но они не в генетике, как у MySQL
Я использую и то и то. Поверьте это не так. Что-то сложное делать на MySQL упаси боже. Начинаются такие танцы с бубном…
Подскажите существует ли в PostgreSQL или MySQL репликация уровня датацентров?

Когда я 4-ре года назад пробовал MySQL Мастер-Мультимастер репликацию, то это всё были с подводными камнями.

Конечно было бы интересно, что бы реплицировались данные не полностью на все сервера. Например есть 4-е датацентра и по 5-ть серверов в каждом. Желательно, что бы данные были на 2-х серверах (там где была запись) и на хотябы на одном в двух других датацентрах.
Если датацентр упал, то он сам отключается (split brain). А на других будет самостоятельно репликация запускаться, что бы данные были на 3-х независимых серверах.
Мультимастер плохо сочетается с реалиционной моделью. Более менее нормальный мультимастер возможен в key-value хранилищах, т.е. лучше Redis я пока ничего не видел. В остальных случаях это либо псевдо мультимастер либо куча минусов.

То что вы описали, походит на псевдо мультмастер и его вполне можно сделать (и мы на одной из работ делали) через pg slony.
Коробочные решения есть для MySQL, но в виде отдельных продуктов. Mature third-party: www.continuent.com/, galeracluster.com/products/ Достаточно молодой от Oracle: www.mysql.com/products/enterprise/fabric.html И ещё вот: mysqlhighavailability.com/5-7-5-labs-multi-source-replication/ И руками ещё люди делают.

Про подводные камни, точнее про то, как всё сделать и камней не задеть, есть хорошая книжка «MySQL High Availability».
Про администрирование не правда. Когда проект более менее мускл надо тюнить и постгрес тоже, При той же настройке репликации. К сожалению, прочитав статью, сложно сказать, что объективное сравнение и раскрыты все стороны обоих БД. Сам больше знаком с мускл, сейчас работаю с постгрес, Сам пытаюсь сравнить и понять, какую БД я использовал бы в следующем проекте с нуля, пока ответа нет (Опустим моменты с PostGIS и специализированными штуками, когда ответ очевиден)
Наличие hstore, arrays, json в 90% делает ответ простым. Сейчас почти в любом мало мальском проекте это будут полезные штуки. Ну и без PostGIS в Postgres есть типы point и gist индексы по ним (с быстрым поиском ближайшего и прочего).
> Асинхронная репликация без цензуры, или почему PostgreSQL завоюет мир
> Прошло более 10 лет, и что мы видим?
Прошло более 10 лет, и мы видим, что большинство сайтов работает на мускуле, а постгр — удел хипстеров от программирования…
Потому что для большинства сайтов хватает и мускуля, а когда приходит время программировать — его хватать перестаёт.
Большинство хостеров поддерживают PHP+MySQL. Поэтому большинство сайтов на них и работает.
Спасибо за интересную статью! Есть еще весьма существенные различия по функционалу между PostgreSQL и MySQL, не отмеченные выше — также не в пользу MySQL.

У PostgreSQL есть некоторые свои нюансы, например, если нужно много UPSERT/MERGE, придется написать свой генератор кода хранимых процедур. Или использовать в качестве такого генератора руки. Но в общем и целом, все это несущественные неудобства, с которыми вполне можно жить.
Это чудесно :)

Redis и MongoDB не нужны, потому что Постгрес проще, удобнее и быстрее. Если бы Ruby был написан на хранимках в Постгресе, он работал бы в три раза быстрее и не падал. Ноду пришлось писать на V8, потому что джаваскриптеры не поняли лицензию Постгреса, а Erlang появился, потому что кто-то просто не умеет пользоваться триггерами и хранимками. K&R после создания C пришлось писать UNIX, потому что они хотели, конечно, написать Постгрес, но ему было не на чем запускаться. C++0X появился только для того, чтобы умные люди перестали писать на C и перешли на Постгрес. Разработка файловых систем нового поколения часто тормозится (особенно ZFS), потому что люди понимают, что с какой стороны не подходи и что не делай, а из-за требований нормальной транзакционности все равно получается Постгрес! Сам Постгрес написан на хранимках Постгреса, мейкфайл выполнен в виде дампа Постгреса, и собирается Постгрес Постгресом.
Странно написано. Ничуть не выгораживаю PG. Скажем так: в определенной специфике его использования я знаю как оно работает в итоге лучше разработчиков ;), а с MySQL знаком довольно таки поверхностно. Но уж прямо какой то откровенный наезд на MySQL.
По мне так ничем они друг от друга не отличаются. Ни каких вот прямо технологических прорывов ни у того ни у другого нет. Да где то одно реализовано лучше «master-slave репликация» или например in-memory движок хранения. Где то хуже, например SELECT count(*) FROM large_table.

По мне так основное отличае в том что MySQL более «прогрессивные» ребята: вм нужен Update OR Insert? Щас мы забацаем вам UPSERT и пофиг что нет такого пока в SQL стандартах. Правда при смене релизов такая «проактивность» иногда выходит боком.

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

Хорошо это или плохо зависит от вашего проекта. Если у вас небольшой сайтик то наверное плохо, нужную вам фичу вы будете ждать годами, прикручивать велосипеды. Таже самая хваленая репликация выросла из откровенного костыля, ну и на мой взгляд, до сих пор выглядит как нечто инородное.
А если у вас БД на пару десятков терр, хитровывернутые клиенты, оптимизированные до уровня эксплуатации особенностей реализации, и сама процедура обновления даже хотфиксного билда превращается в эпопею сроком на несколько месяцев, то консервативность именно, то что вам нужно.
Описание недостатков MySQL напоминает описание недостатков PHP: там что-то сбоку прилепили, тут что-то впилили, здесь фичу вставили, о целостности и «канонiчности» не заботятся почти совсем. В итоге, чтоб понять как оно устроено и как работает, нужно «пофичурно» знать когда и зачем что делали. Но для тех, кто любит, — это не препятствие;-)

Кроме того, ну имеем мы «наготу InnoDB, частично прикрытую стандартом SQL92». С ростом актуальности для некоторых вопроса «а зачем нам в проекте нужна именно реляционная БД с репликацией и транзакциями из коробки» им всё больше требуется не столько SQL, сколько InnoDB.

Получаем, что «сферический» Postgres лучше всего подходит, как некоторые скажут, «для прототипирования» — для случаев, когда нагрузка не важна, а когда дело доходит до highload'а и от проекта уже точно ясно что хотят, и есть людские ресурсы, то неплохо бы переделать всё под InnoDB потому что в InnoDB «нет ничего лишнего», а чего недостаёт, можно дописать самим. Другое дело, что далеко не каждый проект доходит до стадии highload'а.
Насчет highload не соглашусь. Highload для всех разный. У кого-то это база несколько десятков гиг и 100500 запросов клиентов в секунду. Или пару тысяч клиентов, но каждый должен быть отработан за миллисекунду.

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

А бывает Highload когда клиентов пару десятков, но сама база террабайты. Где нельзя просто накатить хотфикс, потому что в случае чего даже восстановление недельного снапшота займет день-другой. Тут уже не прокатит «накатить фикс минорный» или «быстро запдейтить базейку, так как вместе с очень ожидаемым вами бакфиксом мы еще пару совсем не опасных фич прикрутили».

Так что «сферический» это только если с дефолтовыми настройками. У нас слон работает на очень тяжелом Highload c «мультимастером на пару десятков терр.

Лично мое мнение такое — что выбирать разница не большая. Если все, кроме нагрузки вас в вашем PostgreSQL или MySQL устраивает. Если все советы из серии „20 способов увеличить производительность PostgreSQL / MySQL“ вы выполнили, то не имеет смысл смотреть в сторону оппонента, скорее используемая вашим приложением схема работы с реляционной БД неправильная или вообще вам не подходит реляционная модель, и стоит обратить внимание на модные NoSQL.
К сожалению, сжатие данных у Postgresql проигрывает TokuDB.
TokuDB экономит кучу места на SSD, от него не уйти.
Еще одним преимуществом MySQL перед PostgreSQL является возможность использовать «REPLACE INTO».
REPLACE зло — он пытается сделать DELETE для существующей записи
Выставить выбор engines (которые как раз прекрасно выбираются «под задачу») как минус — это честно говоря несколько неожиданно.

Упомянутый Tungsten — я правильно понимаю, что имеется в виду 3d party программа tungsten replicator? Не, она прекрасна что бы гонять данные из одной базы в другую онлайн. Но выставлять ее как фишку Postgre — несколько странно.

Вообще вопросов к статье довольно много, даже куда больше, чем имеет смысл задавать. Тема избитая, холиварная, но в данном случае поданная однобоко.
Для меня БД не цель, а средство, но были проблемы:

PostreSQL уже научился синхронизировать две базы, доступные для записи? Или по-прежнему только в одну можно писать, из прочих только читать?

> PostgreSQL соответствует стандартам SQL-92, SQL-98, SQL-2003 (реализованы все его разумные части) и уже работает над SQL-2011. Это очень круто.

И какой из них предписывает использовать «bytea» вместо «BLOB»? ;)
> PostreSQL уже научился синхронизировать две базы, доступные для записи?

Не поверите: 2ndquadrant.com/en/resources/bdr

И bytea не синоним BLOB.
> Не поверите: 2ndquadrant.com/en/resources/bdr

Не верю: BDR has been developed by 2ndQuadrant, is open source and fully supported for 2ndQuadrant Support customers

Это о какой версии Postgresql тут речь?

> И bytea не синоним BLOB.

Так как же называется BLOB в Postgresql? И по какому из SQL-92, SQL-98, SQL-2003 или SQL-2011 это так?
UFO just landed and posted this here
UFO just landed and posted this here
PL/SQL в определенных ситуациях позволяет нереально оптимизировать работу с данными
Окститесь, молодой человек.
Pl/sql может все что надо и не надо. Я не знаю СУБД которые без привлечения внешки чисто на своём ядре могли бы такое вытворять, а до синтаксиса докапываться это уже даже не знаю как обозвать. В общем нехорошо такие вещи писать.
Полностью поддерживаю автора данной статьи. Я сейчас MySQL забыл как страшный сон(ну не совсем забыл поддерживать приходится:)). В свое время был биллинг на нем, со включенным аккаутингом просто все валилось при 2500 пользователей онлайн. Что только не пытались предпринять, какие оптимизации только не делали. Конечно существуют проекты типа UTM5, но там сам биллинг выполняет роль базы иначе все бы это полегло.
Сейчас даже для самых маленьких проектов использую только Postgres и чем дольше пользуюсь тем больше его начинаю любить. :).

Честно скажу даже не думал что возникают какие то сложности при переходе. В смысле моральных причин. Я просто взял и начал работать с Postgres-ом, для себя сказал — «это просто другая СУБД».
Бред сивой кобылы, Mysql спокойно держит большое количество коннектов, иначе стали бы его люди брать на прод? На нашем проде всё нормально с коннектами, а на вашем что-то не работает… Интересно почему ?? Быть может Вы не умеете его использовать?
Ну да, ну да, все дебилы кроме я :). А набрать в интернете «MySQL валится при включенном аккаунтинге» Такие результаты получали множество моих коллег. И что значит «большое» 1000 или 100000000? Как Вы можете говорить о моем проекте, если Вы его не видели и утверждать что я не умею его использовать?
Забыл сказать, проблема была не в количестве коннектов, radius создает одно соединение, а проблема была в большом insert и update, то есть узким местом было большое количество запросов. Железо и твики не причем. PostgreSQL на этом же желез работает на ура.
Пост интересный, картинка нехорошая своей жестокостью к дельфинам, не трогай млекопитающее
Sign up to leave a comment.