• Go: 10 лет и растём дальше
    0
  • Go: 10 лет и растём дальше
    +6
    package main
    
    import (
        "io/ioutil"
    )
    
    func main() {
        ioutil.WriteFile("out.txt", []byte("Hello"), 0664)
    }
    
  • Памятка евангелиста PostgreSQL: репликанты против репликации
    +2
    Спасибо, советы я принял к сведению, и благодарен за них. Если когда-нибудь придётся снова работать с MySQL и критиковать его — учту.

    > А если Вы и дальше будете рассказывать про «информативность» доклада, я начну перечислять все технические несуразности. И получится очень неловко.

    Странно, вроде бы в самом начале я делаю оговорку: невозможно описать технически корректно и при этом наглядно, и описанное в докладе — лишь грубые схемы, которые позволяют ПРЕДСТАВИТЬ как всё работают, но на деле СЛОЖНЕЙ.
    И оговорки в процессе доклада я тоже делаю.
    Технических несуразиц там много, и я этого никогда не отрицал. Самое важное с моей точки зрения — оставить в голове слушателя картинку про журналы (что это такое и зачем нужно), какие они бывают, какие у них особенности.
    Эта цель вполне достигнута, отзывы и обратная связь это потверждает.

    За сим раскланиваюсь

    P.S. спасибо за советы и критику, учту в будущем.
  • Памятка евангелиста PostgreSQL: репликанты против репликации
    +3
    > Ну вот, как выяснилось, и зря не отслеживал.
    Я предприму последнюю попытку объяснить, в общем-то, очевидные вещи.
    На момент детального исследования параллельного slave я работал разработчиков проекта Target. В моих должностных обязанностях не было «разработки MySQL». Были конкретные проблемы проекта (отстающий slave на 5.5) и просили решения этих проблем.
    Мер принято было много, в целом они помогли.
    ОДНИМ ИЗ пунктов было изучения 5.7 (на дворе был 2014 год и 5.7.3) — поможет ли он с нашими проблемами или нет.
    Мы провели ряд исследований, после коммуникаций с Oracle исправляли бенчмарки и повторяли исследования.
    Никаких удовлетворительных результатов мы так и не получили, и ближе к концу лета 2014 года прекратили исследования.
    Задач много других, 5.7.3 показал себя несостоятельным, имеющиеся проблемы смогли купировать другими способами (и на целый год этого даже хватило), я переключился на другие задачи.
    Изученное и измеренное я оформил в виде доклада, доклад по отзывам людей, оказался информативным — «теперь мы наконец-то поняли, что происходит с репликацией, откуда наши проблемы и как с ними справляться». Минимум три success story есть, не считая отзывов вида «понял про репликацию и журналы из вашего доклада больше, чем после семестрового курса в ВУЗе».
    Значит, доклад полезен людям

    Вам не кажется странным, Алексей, критиковать мои действия с учётом данного контекста? Нигде, подчёркиваю — НИГДЕ — ни формально, ни по факту, ни в ожиданиях руководства не было слов о разработке MySQL. Только исследование, желательно — побыстрей, если не взлетает и непонятно что делать дальше — то забить, и работать над проблемами ПРОЕКТА.
    А не MySQL.

    > Кстати говоря, связался с разработчиками ты уже _после_ доклада. Это важно, и я об этом знаю точно.
    У Вас, Алексей, неверная информация.
    Я общался с Дмитрием Лёневым как минимум дважды:
    1. На MySQL Meetup (которых был сильно раньше highload)
    2. В процессе подготовки доклада к highload — он критиковал мой план доклада и дал много ценных замечаний
    Но Вы «точно знаете», а с этим спорить бесполезно — успел убедиться за длительный промежуток времени
    После доклада я просто повторил описание своего бенчмарка и выдал скрипты. User story: «нагруженный проект хочет смигрировать с 5.5 на 5.7 без даунтайма» я неоднократно описывал раньше.

    Да, особенно круто критиковать доклад годовалой давности с современным MySQL. Впрочем, я почему-то не удивлён — ни подходом к критике доклада, ни повторения доклада (пожалуй, из неупомянутого мной лишь multi-source replication), ни личным выпадам.

  • Памятка евангелиста PostgreSQL: репликанты против репликации
    +1
    Просто отмечаю: в третий раз за эту дискуссию пропускаю личные выпады и гипотезы с негативной коннотацией.

    Оракл подробно запросил у меня детали бенчмарков и их смысл (для какой реальной задачи они нужны). Меня поблагодарили, ушли чинить.
    Потом мне кидали ссылку на один пост про 5.7, но там без даталей было — из личного общения выяснил, что там был прирост что-то порядка единиц процентов на 128 тредов.
    Начиная с этого момента тему в дальнейшем не отслеживал.
  • Памятка евангелиста PostgreSQL: репликанты против репликации
    0
    У Оракла есть все мои скрипты, описание бенчмарков, результаты измерений. Другими словами, полная информация.
  • Памятка евангелиста PostgreSQL: репликанты против репликации
    +1
    Собственно, железо описано на 76 слайде, а все скрипты лежат тут: github.com/zamotivator/2014-highload-mysql
  • Памятка евангелиста PostgreSQL: репликанты против репликации
    +2
    Конкретно мы с админами убили кучу времени на очень простой сценарий (по которому собирались мигрировать на 5.7) — берём мастер пишем бинлоги, потому запускаем догон слейва и проверяем, как быстро он догоняется.
    Мои графики в презентации — это как раз время догона.
    Слайды 76 и 77: www.slideshare.net/tsarevoleg/ss-40969331?related=1
    описывают железо и там есть ссылка на github со скриптами и конфигами/

    Это лишь один из кучи проведённых тестов, но очень важный — если 5.7 работает не лучше чем 5.5, то мигрировать на неё нет смысла — нету решения нашей самой больной проблемы.

    Другой интересный тест — это догон слейва 5.7 с мастера 5.5 — он нужен для миграции без даунтайма — там всё тоже было очень печально, регрессия 40% по сравнению с 5.5
    Впрочем, это было на 5.7 годичной давности, и я уже не работаю в компании mail.ru, где снова актуально перепроверить результаты на новой версии
  • Памятка евангелиста PostgreSQL: критикуем MySQL грамотно
    +1
    Ещё Avito и Zalando
  • Возможности PostgreSQL, которых нет в MySQL, и наоборот
    0
    Ну, пусть так. Только что делать с CPU-bound репликацией на нагруженных проектах — вопросов остаётся открытым
    Да, я знаю workaround'ы — записать general query log, построить по каждому типу запроса сводную статистику average response time и total time, отранжировать и исправить/убрать запросы
    Понятно, что можно базу распилить.
    Но это выглядит немного эээ странно, — у мастера ещё большой запас по CPU и IO, а реплика уже сдохла.

    Не было бы этой проблемы — не было бы моего доклада. И судя по фидбеку после доклада — многие с этим наелись, и как решать — никто не понимает
  • Возможности PostgreSQL, которых нет в MySQL, и наоборот
    0
    Ну, если так, то странно почему не упомянут разбор различных типов журналов (логический/физический), их компаративный анализ, а также бенчмарк MySQL 5.7

    В причинах тормозов не разобрались — вы правы, однако у меня задачи в проекте стояли несколько отличные от «починить mysql».
    И я до сих пор очень хочу увидеть исследование LOGICAL_CLOCK в 5.7, которое:
    — показывает существенный прирост производительности репликации
    — указано железо и настройки
    — указаны числа в эксперименте

    Сейчас 5.7 выглядит странно — вроде есть крутая фича, которая должна давать практически линейный прирост, но по факту я его даже измерить не смог
  • Возможности PostgreSQL, которых нет в MySQL, и наоборот
    0
    Света, самое печальное — я до сих пор не видел ни одного исследования slave_parallel_type=LOGICAL_CLOCK, где было бы существенное улучшение производительности, и где были бы приведены числа и настройки.

    Т.е. девушка есть, но мы вам её не покажем.
  • Возможности PostgreSQL, которых нет в MySQL, и наоборот
    +2
    Алексей, спасибо за краткий пересказ моего доклада, я буду это цитировать.
  • PostgreSQL vs MySQL
    +1
    Боюсь, вы не понимаете всей проблематики и просто не тестировали ваш код под серьёзной нагрузкой — потому и не столкнулись с проблемами.
  • PostgreSQL vs MySQL
    0
    Смотрите мой комментарий ниже про B-Tree
  • PostgreSQL vs MySQL
    0
    которая пишется за неделю и занимает тысячу строк кода

    Это неправда. Задам два простых вопроса: насколько консервативен алгоритм объединения страниц в вашей версии «на тысячу строчек кода» и как у вас дела 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
  • PostgreSQL vs MySQL
    0
    Ну, коллеги в мыле используют, с ними постоянно общаемся.
    У PostgreSQL проблемы есть, но они не в генетике, как у MySQL
  • PostgreSQL vs MySQL
    +3
    Зависит от конкретного альтера, но чаще нет, чем да.
  • PostgreSQL vs MySQL
    0
    Ну тут не в удовлетворении дело… :) Меня просто интересуют сложные ситуации на продакшене. Вот и докапываюсь, откуда ноги растут, наступившие и победившие грабли.

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

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

    Конечно, имеет. table inheritance для поддержания ссылочной целостности требует CHECK, а его нет.
  • PostgreSQL vs MySQL
    0
    Вы не поверите, в Oracle тот же самый алгоритм — Cascades
  • PostgreSQL vs MySQL
    +6
    Например, офигенный оптимизатор: citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.98.9460 богатые типы данных, очень классные интерактивные инструменты анализа производительности, широкая поддержка стандартов

    Microsoft Windows — ужасная платформа, а вот Microsoft SQL Server цены нет.
  • PostgreSQL vs MySQL
    +3
    С удовольствием!
    Прогресс — непрерывное поступательное движение вперёд.

    И да, опыт использования для мелких проектов есть, функциональную часть я имел возможность оценить
    Касательно нагруженных проектов — пока опыта нет, к сожалению, но надеюсь, что скоро приобрету :)
  • PostgreSQL vs MySQL
    +8
    :)
  • PostgreSQL vs MySQL
    +3
    Что не мешает использовать PostgreSQL в 1С, немало пользователей.

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

    Ровно это я хотел сказать, и ровно это и было сказано :)
  • PostgreSQL vs MySQL
    +2
    Если я всё правильно понял из статьи, то там прямо говорится, что Бегун запилил свой 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

    Триггеры часто запрещены безопасниками.
  • PostgreSQL vs MySQL
    +23
    Простите, но «мой» порошок — это как раз MySQL.
    Я над ним работал в Percona, занимался как раз репликацией.
    Я с ним вожусь в Mail.Ru Target, постоянно, и помогаю коллегам.

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

    И, к сожалению, я вынужден констатировать, что причин выбирать MySQL для новых проектов практически не осталось.
    Хотя MySQL — мой хлеб.
  • PostgreSQL vs MySQL
    +2
    Если PostgreSQL не умеет так, что он может предложить для масштабирования 1С?

    Умеет. Называется BDR — bidirectional replication.
  • PostgreSQL vs MySQL
    +6
    К сожалению, у MySQL в сравнении с PostgreSQL очень мало плюсов, и их становится всё меньше.
  • PostgreSQL vs MySQL
    +3
    Одна БД + пачка терминалов это просто.

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

    Для репликации нужно два сервера с базой данных и репликация между ними.
  • PostgreSQL vs MySQL
    0
    Я не знаю, что такое «тупой» в отношении СУБД.
    Я не говорил «тупой», я говорил «имеет меньше возможностей» и «практически не имеет оптимизатора».
  • PostgreSQL vs MySQL
    +3
    Покажите, пожалуйста, мне систему, в который сделан и работает честный master-master.
    Это миф. Нету таких. Или практически нету. Или до первого развала кластера или полной остановки при падении одного из узлов.

    Я не специалист в 1С, но вы ТОЧНО уверен, что на терминалах стоит своя версия СУБД и что там мастер-мастер между терминалами и базой?
    Насколько мне известно, база одна, а терминалы и все остальные — клиенты к ней.
  • PostgreSQL vs MySQL
    +7
    Вангую, что это не проблема проверки ссылочной целостности на уровне БД (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, без которого в сложных проектах жизнь становится горькой
  • PostgreSQL vs MySQL
    +2
    Кластерные индексы — интересная тема. Да, в отдельных случаях они ускоряют запросы.
    В PostgreSQL есть www.postgresql.org/docs/9.3/static/sql-cluster.html- не кластерные индексы, конечно, но позволяет достичь схожих результатов
  • PostgreSQL vs MySQL
    +3
    Мучительно. С остановкой записи, либо через триггеры (при помощи percona-toolkit)
  • PostgreSQL vs MySQL
    +1
    Это семисинхронная репликация, со всеми плюсами и минусами.
    Я лично практически не видел проектов, где действительно нужен мульти-мастер.
  • PostgreSQL vs MySQL
    +7
    И какое это имеет отношение к ссылочной целостности?

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

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

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

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

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

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

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

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

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

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

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

    Не в MySQL, а в InnoDB. И таких базовых проверок явно недостаточно.
  • PostgreSQL vs MySQL
    +19
    Из забытого в статье: благодаря хорошему журналу, у PostgreSQL полностью транзакционный DDL (data definition language) — т.е. можно в транзакциях менять схему данных, и эти изменения буду транзакционными.
    MySQL о таком даже мечтать не смеет, к сожалению.
  • PostgreSQL vs MySQL
    +4
    К сожалению, примерно так сейчас выглядит положение MySQL в сравнении с PostgreSQL.
    Исключение — гиперогромные проекты, вроде Facebook, в которых MySQL (точнее, InnoDB) используется как B-Tree хранилище по ключу.

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

    К тому же, с появлением движка sophia в tarantool ситуация становится гораздо неоднозначней — не будет ли sophia лучше, чем MySQL?
  • PostgreSQL vs MySQL
    0
    На полном серьёзе. Один из наших демонов, работающий как slave к MySQL, мониторит ссылочную целостность (ему без неё слишком грустно) и выводит специальную админку, в которой показывает висячие ссылки.

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

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