Проміжні міграції бази даних для автоматичного оновлення

[konfuciusu]

Поки що єдиний спосіб, як всім працювати із однаковою базою після оновлень torrentpier - це:

git checkout master
git pull upstream master
docker-compose pull
docker-compose down --volumes
docker-compose up -d
docker-compose exec toloka composer update

... фактично drop + import, що означає втрату локальних змін. Також людям може бути не очевидно, коли треба робити docker-compose down --volumes, а коли ні.

Тому треба вже зараз (навіть поки немає міграції із старої Толоки), почати користуватися Phinx'ом doctrine migrations (#74). Для цього його треба додати в composer і в docker-compose, щоб міграція запускалася автоматично при docker-compose up -d

[konfuciusu]

@AIlkiv, можете встановити Phinx через composer і згенерувати початкову міграцію?

а я подбаю про docker-compose

[AIlkiv]

Так не вийде, бо початкова міграція це база toloka_old.
А для тих хто клонує репозиторій необхідна актуальна база torrentpier 2.
Тобто фактично початкова міграція + та що я розробляю

[yukoff]

Думаю, можу з цим допомогти. Між іншим, перевірив у docker-і - конвертація бази в utf8mb4/utf8mb4_unicode_ci покращує вибірку пошуку, перевірив із заголовком "Ґінтама / Gintama", пошуковий запит "Гінтама" спрацьовує, до конвертації - ні.

P.S. Непогана стаття на тему https://blog.codinghorror.com/get-your-database-under-version-control/

[konfuciusu]

Міграція з Толоки може ще зайняти певний час, тому щоб не блокувати розробку, я би все ж створив початкову міграцію з https://github.com/hurtom/toloka/blob/master/install/sql/mysql.sql

[yukoff]

Яку точку брати за стартову? v2.2.1 чи останню після мержу v2.2.2 (#63)?

[konfuciusu]

Не принципово, але я би взяв v2.2.1, щоб вже був приклад першої міграції.

[yukoff]

@konfuciusu Солідарний. Але треба буде обдумати, як міграція відбуватиметься - бо статус бази пишеться в неї ж, і міграцію старої треба буде додати перед цією - бо якщо на старій толоці скрипт міграції спробує виконати апдтейт з, типу, v2.2.1 на v2.2.2, тут він і помре )

Я маю на увазі, що можна це зробити а) альтерами б) створити data feed міграції, котрі старі дані внесуть у нову базу (зі старої структури в нову).

Тут я ще ось, що думаю - оскільки подальша розробка TP ведеться з використанням laravel (який в свою чергу використовує docrine), то мабуть варто зупинитись на ньому (міграції phinx-у просто трохи можна адаптувати, чекаємо на PR від @AIlkiv).

Phinx та Doctrine майже ідентичні, за винятком того, що останній вміє diff без сторонніх пакетів, єдиним конкурентом тут їм є liquidbase (і якщо б була потрібна підтримка різних БД, то варто б мабуть було зупинитись на ньому, хоча поки плагіни тільки під Grunt є).

[konfuciusu]

Стара Толока - це окрема тема. Там міграція буде проходити один раз і в напів-ручному режимі. Я готовий до цього і не очікую від скриптів, що вони все зроблять автоматично.

Задум такий, що ми зараз за основу беремо v2.2.1, а додаткові таблиці і інші зміни зі старої Толоки влиються і це тоді стане v3.0.0

[yukoff]

@konfuciusu З міграцією можу допомогти - і стратегію розробити, і процес автоматизувати по максимуму. В ідеалі щось типу на dev.toloka зробити реплікацію з основної бази, а з нею вже обкатати міграцію.

P.S. А який наразі розмір бази фізичний, та якщо є такі дані - кількість рядків в найбільших таблицях.

[konfuciusu]

Буду вдячний за детальний палн.

Загальний розмір - трохи більше 4 ГБ.

Найбільше рядків:
bb_bt_tor_dl_stat - 15 млн (600 МБ)
bb_bt_users_dl_status - 14 млн (350 МБ)
bb_attachments_rating - 4 млн (90 МБ)
bb_users - 900 тис (1,2 ГБ)

[yukoff]

Ага, зрозумів. Судячи з того, що база в innodb чи не планується FK розвісити? Про innodb_file_per_table = 1 можна ж не питати? ;)

Як закінчимо з кодом для міграцій - продумаємо оптимальний шлях і який downtime можливий (ну, точніше думаю все буде досить таки наживо, але краще б на той час виключити можливість запису в базу). Плюс, якщо потрібен зовсім малий даунтайм, можна швиденько перейменувати старі таблиці, створити нові, вставити останній запис (чи просто пустий - взагалі це потрібно, щоб закріпити автоінкремент, якщо він є), та в фоні переливати решту. Ну, згодом вже детальніше будемо дивитись.

[yukoff]

bb_users - 900 тис

А непогано 😉

[konfuciusu]

Якщо FK необхідні, я не проти.

З InnoDB не все так просто. Upstream досі використовує MyISAM, і це не без причини. Так само і стара Толока має тільки декілька таблиць в InnoDB (bb_topics, bb_users), де це дійсно дало перевагу через table-level locks. Ми пробували перенести всю базу, але це призвело до суттєво більшого навантаження і сповільнило сайт. Правда, це було ще за часів MySQL 5.5 і скоріш за все, це можна виправити, якщо оптимізувати запити. Зрозуміло, що ми забрали запити із SELECT *, але цього було не достатньо, і довелося повертатися до MyISAM.

[yukoff]

Так, не все так просто - без аналізу та додавання релевантних індексів просто так не перейти, може суттєво вирости час обробки запитів просто тому, що MyISAM з InnoDB по різному зберігають індекси та працюють з ними, і для ефективної роботи InnoDB не було потрібних індексів. Якщо не помиляюсь, то в старій базі є таблиці взагалі без індексів, наразі і в старій, і в новій версії бази є таблиці без PK.

До речі, я б радив на перкону мігрувати - там ще більш ефективний рушій (XtraDB, бінарно сумісний з InnoDB, тобто drop-in заміна), плюс є можливість вести лог повільних запитів.

[konfuciusu]

Я за MariaDB 10.2+. Лог повільних запитів ведемо.

[yukoff]

Я не знаю, в чому перевага MariaDB (ну, окрім активної спільноти розробників зі всього світу (а не тільки з Ораклу), прозорого ліцензування і відсутністю за продуктом ім'я корпоратів Oracle), до того ж MariaDB до версії 10.1 типово використовували саме XtraDB варіант InnoDB від Percona (і саме в ньому лог повільних запитів, хоча в світі InnoDB можливо й відбулися зміни за останні 3-4 роки). З версії 10.2 вони чомусь знову стали використовувати типовий InnoDB.

[yukoff]

Щодо міграцій - вирішив узгодити з авторами TP torrentpier/torrentpier#427, чи є в них плани щодо цього, як я й казав, вони рухаються в сторону laravel (doctrine):

in the future on experimental branch we want to move on full Laravel-stack, thus database migrations and seeding will be based on it.

Перед мержем трохи адаптую, щоб в майбутньому було менше проблем при оновленні версій.

[konfuciusu]

XtraDB in 10.2 is not up to date with the latest features of InnoDB and cannot be used.

https://mariadb.com/kb/en/mariadb/what-is-mariadb-102/

XtraDB had many great improvements over InnoDB in 5.1 and 5.5. But over time, MySQL has implemented almost all of them. InnoDB has caught up and XtraDB is only marginally better.

the only real improvement that XtraDB 5.7 seems to have is for a write-intensive I/O-bound workload, where innodb_thread_concurrency control is disabled. With a proper innodb_thread_concurrency, XtraDB is only marginally better.

https://mariadb.com/kb/en/mariadb/why-does-mariadb-102-use-innodb-instead-of-xtradb/