Як вибрати механізм бази даних MySQL

Зокрема, як ви обираєте між MyISAM та InnoDB, коли жодна з них не вимагає необхідної функції (наприклад, вам не потрібні сторонні ключі).

Чи завжди це зводиться до спроб і вимірювання? Або існують хороші правила щодо кількості та частоти читання проти запису, та інших подібних заходів? Чи впливає розмір столу на типовий вибір?

Відповідь - завжди слід вимірювати, бажано, якщо це можливо, власні дані та навантаження.

Оскільки шаблони доступу до даних можуть сильно відрізнятися від програми до програми, важко сказати і, швидше за все, неможливо визначити "найкращий" механізм зберігання даних для всіх навантажень.

Однак, у просторі MySQL є дуже обнадійливі події, які минулого тижня відвідали MySQLConf / Percona Performance Conf.

Деякі з альтернативних двигунів зберігання:

1. XtraDB (вилка InnoDB)
2. Плагін InnoDB
3. PBXT
4. TokuDB

Крім того, Percona, Google та ін. Внесли патчі, які чудово допомагають у роботі InnoDB. Особисто я керую збіркою OurDelta. Це добре працює для мене, і я закликаю перевірити побудови OurDelta та Percona.

Якщо це просто проста система зберігання / звітів, я використовую MyISAM для її сирого виконання.

Я б використовував InnoDB, якщо мене турбували багаточасні звернення з великою кількістю записів, щоб скористатися блокуванням на рівні рядків.

Існує велика кількість орієнтирів для різних двигунів баз даних MySQL. Існує гідний, який порівнює MyISAM, InnoDB та Falcon у блозі про Percona MySQL Performance , дивіться тут .

Інша річ, яку слід врахувати між двома вищезгаданими двигунами (MyISAM та InnoDB) - це їхні підходи до блокування. MyISAM виконує блокування таблиць, а InnoDB - блокування рядків. Слід враховувати різноманітні речі, не тільки чіткі показники ефективності.

Є функції, які з експлуатаційних міркувань вам будуть дуже корисні, навіть якщо ваша програма їх абсолютно не вимагає:

• InnoDB має MVCC, що означає, що ви можете робити послідовні резервні копії, що не блокують
• InnoDB має автоматичне відновлення, а це означає, що після нечистого відключення немає тривалих операцій з ремонту таблиці
• З InnoDB читачі ніколи не блокують авторів, і навпаки, означаючи (загалом кажучи) більшу одночасність (це не означає, що в загальному випадку краща ефективність роботи)
• InnoDB кластерізує свої ряди на первинному ключі, що МОЖЕ означати меншу кількість операцій вводу-виводу для операцій зчитування, якщо первинний ключ був обраний достатньо вдало.

Тож, незважаючи на обмеження закордонних ключів, ви, мабуть, хочете використовувати InnoDB так чи інакше.

Звичайно, це ServerFault, а не переповнення стека, тому правильна відповідь:

• Ви завжди повинні використовувати двигун, який обрали розробники додатків
• Якщо вони не обрали певний двигун, вони не дуже серйозно ставляться до використання MySQL і, ймовірно, не знають, як правильно ним користуватися.
• Ви не можете переключитися на інший двигун, на той, на який перевірена ваша програма, він може вводити помилки.

Мій провайдер хостингу порадив нам повністю позбутися MyISAM і перейти на InnoDB, якщо це неможливо.

У нашому випадку у нас була жорстка корупція даних, яка почала проявлятися від декількох до декількох разів на день, завжди вимагаючи ПОТОРНОЇ ТАБЛИЦІ та відповідних команд, що займало століття у великих таблицях.

Після того, як ми перетворили (або: були перетворені) в InnoDB, проблеми миттєво зникли. Недоліки / застереження у нас були:

• Неможливо перетворити таблиці з індексом FULLTEXT (ця проблема пішла з часом сама по собі; її замінили рішення на основі Solr / Lucene, яке все одно має набагато кращу якість)
• Великі таблиці з мільйонами рядків, які часто вимагають COUNT (*), були дуже повільними, і ми не змогли їх переключити.

Але зверніть увагу: це все специфічно для нашого середовища тощо, тому воно, як правило, не може застосовуватися.