|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
27.07.2016, 09:28
|
|||
|---|---|---|---|
Переход с MySQL на PG |
|||
|
#18+
Есть приложение на PHP достаточно нагруженное. Задумались о переходе с MySQL на PG. База данных примерно 50 таблиц, ~20 триггеров, 10 ХП, ~100GB данных Написать миграцию для перехода не вариант. Например, дамп MySQL загружается на машину с SDD дисками около 6-8 часов, поэтому слить данные в дамп, конвертнуть его и залить - не вариант, слишком долго и слишком рискованно. Естественно таблицы связаны между собой и переносить их по одной тоже не простой вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2016, 10:44
|
|||
|---|---|---|---|
|
|||
Переход с MySQL на PG |
|||
|
#18+
HettЕсть приложение на PHP достаточно нагруженное. Задумались о переходе с MySQL на PG. База данных примерно 50 таблиц, ~20 триггеров, 10 ХП, ~100GB данных Написать миграцию для перехода не вариант. Например, дамп MySQL загружается на машину с SDD дисками около 6-8 часов, поэтому слить данные в дамп, конвертнуть его и залить - не вариант, слишком долго и слишком рискованно. Естественно таблицы связаны между собой и переносить их по одной тоже не простой вариант. Ну все равно. Будет долго. А так я за ~2-3 часов гугления нашел несколько приложений по переносу данных из MySQL в PostgreSQL. Причем я хотел наоборот ч/з дамп. А нашел, ч/з соединения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2016, 13:41
|
|||
|---|---|---|---|
Переход с MySQL на PG |
|||
|
#18+
mad_nazgul, Тут Uber написал пост , что они перешли в обратном направлении, сообщество гудит. Josh Berkus достаточно хорошо описал тест-кейс , который характеризует их нагрузку. Почитайте и сравните со своей моделью данных, чтоб не было потом больно. (В той же ветке есть ссылка на ycombinator , где также идёт обсуждение.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2016, 14:18
|
|||
|---|---|---|---|
Переход с MySQL на PG |
|||
|
#18+
vyegorovТут Uber написал пост Чувак рассказывает, какая в MySQL крутая репликация? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2016, 14:44
|
|||
|---|---|---|---|
|
|||
Переход с MySQL на PG |
|||
|
#18+
> Uber написал пост, там рукалицо почти везде везде ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2016, 14:57
|
|||
|---|---|---|---|
Переход с MySQL на PG |
|||
|
#18+
Misha Tyurin> Uber написал пост, там рукалицо почти везде везде проблема вакуумирование, а главное -- ужатия индексов быстроменяющихся табличек (у меня -- таблички логических блокировок 100--2000 постоянно удаляемых записей при 100++МБ в индексах и самой табле) -- таки существует. /* под такие таблички хорошо пошел бы чисто блокировочный движок. хотя, боюсь, есть теоретическая проблема совместного использования двух механизмов поддержания транзакционности одновременно, "в одном пространство--времени". */ то, что тут постгрес сосёт даже у других версионников -- например у оракла, какбе общее место. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2016, 15:11
|
|||
|---|---|---|---|
Переход с MySQL на PG |
|||
|
#18+
Misha Tyurin> Uber написал пост, там рукалицо почти везде вездехотя беглого взгляда на картинки достаточно, чтобы усомниться в компетенции афтара ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.07.2016, 15:23
|
|||
|---|---|---|---|
Переход с MySQL на PG |
|||
|
#18+
Misha Tyurin, Я бы акцентировал внимание на кейсе Джоша и qwwq — небольшая табличка с очень высокой вовлеченностью “везде”. Будет пухнуть, чем дольше транзакции, тем больше будет пухнуть. Не говоря про индексы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2016, 12:13
|
|||
|---|---|---|---|
|
|||
Переход с MySQL на PG |
|||
|
#18+
vyegorov, мы у себя такие и подобные таблицы в фоне реиндексим периодически и/или пересоздаем/ротирвем_по_кольцу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2016, 12:14
|
|||
|---|---|---|---|
|
|||
Переход с MySQL на PG |
|||
|
#18+
vyegorov, суть куча то не распухает, так как вакуум, а индексы -- да, пухнут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2016, 12:17
|
|||
|---|---|---|---|
|
|||
Переход с MySQL на PG |
|||
|
#18+
НО! чтобы не быть заложниками этого тупого поста от юбера, скажу так: там ложная дилемма, -- они не про сравнение "баз", а про свой хитрый орм ("schemaless" или как он там у них) с шардингами json-ами и прочим носиквел ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2016, 12:29
|
|||
|---|---|---|---|
|
|||
Переход с MySQL на PG |
|||
|
#18+
Misha Tyurin, https://eng.uber.com/schemaless-part-one/ https://eng.uber.com/schemaless-part-two/ https://eng.uber.com/schemaless-part-three/ от майсикуель, там суть ничего ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2016, 12:44
|
|||
|---|---|---|---|
Переход с MySQL на PG |
|||
|
#18+
Misha Tyurin, Я понимаю, что они там всё сумбурно делали, репликация так совсем печальная у них была. Согласен, что это совсем не пример для подражания. Но всё же они правы в том, что в ПЖ есть свои проблемные стороны, которые могут стать неожиданностью, особенно при переходе с другой базы. Нужно это осознавать и уметь их обходить. Собственно, ради этого и упомянул. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2016, 12:54
|
|||
|---|---|---|---|
|
|||
Переход с MySQL на PG |
|||
|
#18+
vyegorov, https://eng.uber.com/mezzanine-migration/ > они правы в том, что в ПЖ есть свои проблемные стороны ну у всего есть свои ограничения, всё так или иначе продукт компромииса. т это вроде и так очевидно, без постов от авторов. но, НЕТ, они не правы. они не упирались в "базу", причина была в их организации, и они решили написать свой "движок". имеют право. но пост тогда надо было иначе позиционировать. у нас, например, есть все характерные черты (шардинги, жейсоны, "триггера" обратно в приложение) их Скималесса, но мы при этом работаем поверх pg ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.07.2016, 13:44
|
|||
|---|---|---|---|
Переход с MySQL на PG |
|||
|
#18+
Misha Tyurin, Да я же и не спорю, что они не правы. И репликация у них не продумана от слова “совсем” — логическую надо было строить, а не каскады. И я подумал в первую очередь про вас (как компанию) и про скайп (Ханну в своё время рассказывал, как они строили свой кластер в начале развития). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.07.2016, 09:46
|
|||
|---|---|---|---|
|
|||
Переход с MySQL на PG |
|||
|
#18+
Hett, Проблема для Вас все еще актуальна? Или нашли какое-то решение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.07.2016, 11:18
|
|||
|---|---|---|---|
Переход с MySQL на PG |
|||
|
#18+
ywHett, Проблема для Вас все еще актуальна? Или нашли какое-то решение? Да мы не торопимся. Пока изучаем вопрос. Подходящего для нас решения пока не нашли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.07.2016, 12:52
|
|||
|---|---|---|---|
Переход с MySQL на PG |
|||
|
#18+
Hett, Ну... я сейчас тестирую прыжок на новую версию ПЖ, у меня получается ~500GB перенести dump/restore в течении 6 часов (5 баз), если отложить не-уникальные индексы, то на час меньше. Мне кажется, что 100GB на SSD можно вогнать достаточно быстро (часа 2 от силы), надо только продумать стратегию и обкатать процесс несколько раз. Сколько у вас RAM-а на новой машине и как далеко (по сети) сервера между собой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.07.2016, 14:29
|
|||
|---|---|---|---|
Переход с MySQL на PG |
|||
|
#18+
Сейчас посмотрел, не 100, там 180. По крайней мере в MySQL дамп заливался часа 4-5 на сколько я помню. Тут еще все зависит от количества индексов наверное. Сервера нормальные, 64 ОЗУ, 24 ядра. При такой миграции еще проблема, что после нее полезут косяки тоннами. Там достаточно много сложных запросов, нужно очень долго и трепетно все переделывать. Ну или не все, но многое. Поэтому хотелось бы постепенно. Кстати есть мысль попробовать выделить логику отдельными блоками, там где не используются связи между группами таблиц и переносить по группам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.07.2016, 17:31
|
|||
|---|---|---|---|
Переход с MySQL на PG |
|||
|
#18+
Hett, Тут в любом случае нельзя наскоком. Несколько независимых “направлений” в разработку: - скорость самой миграции. Я бы поставил маленькие шареные буфура (1GB), аггресивный bgwriter (всё на максимум), отключил бы synchronous_commit, выкрутил бы maintenance_work_mem (для индексов, до каких 8GB). Подумал бы, как дампнуть всё в виде отдельных таблиц (1 таблица == 1 файл) с целью параллелизации - косяки. Вам необходимо привести схему к такому виду, который понимает ПЖ — поменять типы, причесать определения функций, избавиться от специфических параметров - приложения. Я бы включил логгирование всех запросов на день (больше — лучше) и потом тупо бы их скормил тестовой ПЖ базе, чтобы найти те, которые совсем не работают. Потом бы “скормил” бы их много раз и занялся бы оптимизацией самых медленных. Это проект на несколько недель, с привлечением ДБА, сис-админов, девелоперов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.07.2016, 13:50
|
|||
|---|---|---|---|
|
|||
Переход с MySQL на PG |
|||
|
#18+
Hettхотелось бы постепенно. Для "постепенно" нужна репликация master-master. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
01.08.2016, 12:35
|
|||
|---|---|---|---|
|
|||
Переход с MySQL на PG |
|||
|
#18+
Hett, Могу предложть программу, используемую нашей компанией. Это продукт собственной разработки, предназначен для миграции/синхронизации данных и метаданных между разными СУБД (Сейчас поддерживаются Oracle, PostgreSQL, MSSQL, DB2, MySQL, H2). Примерная схема работы: 1. Мигрируется структура таблиц: названия колонок, типы, размерность, комментарии, значения по умолчанию и т.п (По времени это примерно 1-2 мин.) 2. Анализ соответствия структур таблиц. (5 мин - 1 ч) 3. Миграция данных. (предположительно 1 ч - 10 ч) 4. Анализ ошибочных записей (так, например, PosgreSQL "не любит" когда в поле типа TEXT попадает 0x00, а Oracle и MySQL это допускают), написание скриптов для коррекции таких записей, их выполнение и повторная попытка миграции (п.3) 5. Создание связей таблиц, индексов (в зависимости от данных от 30 мин - до нескольких часов) 6. Миграция "специфичных" объектов (ХП, триггеры, создание ролей,раздача прав и т.п.), 7. Тестирование работы своей программы с новой базой, по необходимости внесение изменений (по времени это может быть от 1 дня до нескольких месяцев). Наша программа выполняет п.1,2,3,5. Все остальное работа ваших dba и разработчиков. Если в п.4 много ошибочных записей, то я бы рекомендовал предварительно клонировать рабочую базу MYSQL (или отдельные таблицы), и все коррекции проводить на копии В целом работа потребует много времени и внимания при подготовке миграции, сам же процесс миграции относительно непродолжителен. Так, недавно переводили наш транспортный сервис из Oracle на PostgreSQL (~200 таблиц, 8 ХП, самая объемная таблица GEO-позициорования ~700 млн записей, средний размер записи порядка 150-200 байт). Подготовка заняла около недели, сама же миграция прошла за 15 часов. Программа пока используется как внутрикорпоративный вспомогательный продукт, в перспективе руководством принято решение выводить его на рынок, но с маркетинговой политикой пока не определились, так что, если интересно что и как, можете связаться с руководством (e-mail: ru@altsoft.biz) P.S. В течении 1-2 недель постараюсь сделать небольшое видео по миграции какой-нибудь тестовой базы данных и выложить для более наглядного представления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.08.2016, 11:43
|
|||
|---|---|---|---|
|
|||
Переход с MySQL на PG |
|||
|
#18+
Misha Tyurinvyegorov, https://eng.uber.com/mezzanine-migration/ > они правы в том, что в ПЖ есть свои проблемные стороны ну у всего есть свои ограничения, всё так или иначе продукт компромииса. т это вроде и так очевидно, без постов от авторов. но, НЕТ, они не правы. они не упирались в "базу", причина была в их организации, и они решили написать свой "движок". имеют право. но пост тогда надо было иначе позиционировать. у нас, например, есть все характерные черты (шардинги, жейсоны, "триггера" обратно в приложение) их Скималесса, но мы при этом работаем поверх pg Вот пишут - они правы или это притянуто за уши? авторWe encountered many Postgres limitations: Inefficient architecture for writes Inefficient data replication Issues with table corruption Poor replica MVCC support Difficulty upgrading to newer releases We’ll look at all of these limitations through an analysis of Postgres’s representation of table and index data on disk, especially when compared to the way MySQL represents the same data with its InnoDB storage engine. Note that the analysis that we present here is primarily based on our experience with the somewhat old Postgres 9.2 release series. To our knowledge, the internal architecture that we discuss in this article has not changed significantly in newer Postgres releases, and the basic design of the on-disk representation in 9.2 hasn’t changed significantly since at least the Postgres 8.3 release (now nearly 10 years old). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
02.08.2016, 12:37
|
|||
|---|---|---|---|
|
|||
Переход с MySQL на PG |
|||
|
#18+
Так Юбер уже один раз мигрировал в 2012 году, в обратную сторону MySQL->PG, и тогда всё было тоже обосновано https://www.yumpu.com/en/document/view/53683323/migrating-uber-from-mysql-to-postgresql ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=53&mobile=1&tid=1997077]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
152ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
34ms |
get tp. blocked users: |
1ms |
| others: | 215ms |
| total: | 430ms |
| 0 / 0 |
