Я створюю модуль, де кожен користувач часто отримує запис у таблицю протягом 10 - 300 секунд.

Коли час закінчується, запис видаляється. Випадок такий: користувачів буде дуже багато, і записи будуть змінюватися дуже часто - як це вплине на продуктивність програми для цієї таблиці, тому що записи змінюватимуться дуже часто, і мені цікаво, чи з цим добре буде mysql? Подібно до того, як індекси будуть приходити та йти, дані змінюються як 200 разів / секунди для цієї конкретної таблиці. Можливо, я вибираю погане рішення для такої роботи. Будь-які пропозиції ?

Дякую!

Одне, що потрібно враховувати, - це те, як MySQL використовує буфери для своїх основних механізмів зберігання даних: InnoDB та MyISAM .

Те, що лежить в пам’яті, сильно відрізняється між цими системами зберігання даних.

InnoDB кешує як дані, так і сторінки покажчиків. Вони завантажуються в буферний пул InnoDB, розмір якого розмір innodb_buffer_pool_size .

MyISAM кешує лише індексні сторінки, і вони завантажуються в кеш-пам'ять клавіш (Key Buffer), розмір якого розмір key_buffer_size .

Ви повинні використовувати information_schema.tables, щоб отримати дані та розміри індексу, зайняті на диску, щоб правильно розмістити пул буфера InnoDB та кеш-ключ MyISAM .

Залежно від того, скільки у вас є даних і скільки часу ви дозволите, ви можете зігріти кеші таким чином:

Для кожної таблиці TableT

• перейти до кожного індексу NDX
• для кожного індексу NDX
  • запустіть SELECT кожен стовпець у NDX, принаймні один стовпець, не індексований у TableT від TableT

Цим ви гарантуєте, що кожну сторінку даних та покажчиків читайте хоча б раз Вони будуть сидіти в схованку. Ця концепція частково і в принципі практикується Перконою . Перкона вбудував цю концепцію в mk-slave-prefetch . Що ця програма робить

• читати журнали ретрансляції на підлеглому, перш ніж підлеглий обробляє в ньому SQL
• взяти оператор SQL з журналу ретрансляції та перетворити його в SELECT, використовуючи пропозиції WHERE, GROUP BY і ORDER BY як керівництво до вибору індексів
• виконати оператор SELECT, який прийшов з перетвореного SQL

Це змушує підлеглого мати 99,99% даних, необхідних підлеглому для швидкої обробки SQL. Це також робить раба підготовленим у випадку, коли ви вручну переходите на раба і просуваєте його до господаря, КОГО КАШИ ПОДІЄТЬСЯ ПРО ТЕБЕ, ЯК МАЙСТЕР, ЩО ВИ НЕ ПОТРІБНО.

ВИСНОВОК

Ніщо не може бути готовим, бажаючим і здатним кешами для використання в обстановці важких ВСТАНОВЛЕННЯ, ОНОВЛЕННЯ та ВИДАЛЕННЯ.

Спробувати !!!

КАВАТИ

З народженням продуктів, таких як запам’ятовування, деякі відійшли від необхідності належної настройки MySQL. Зрозуміло, що багато сайтів отримують перевагу від збільшення завантаження даних, що забезпечується керуванням кешування поведінки даних, оскільки розробники швидко бачили з запам'ятовуванням. Багато інших сайтів, лише перемикаючи накопичувачі двигунів або правильно налаштовуючи MySQL, зрозуміли ті самі переваги продуктивності. Перш ніж відмовитися від бази даних і суворо використовувати її як сховище, максимально використайте свою базу даних. Дотримуйтесь уважної уваги, і ви можете бути приємно здивовані тим, що MySQL зробить для вас.

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

"Багато користувачів" насправді нікому не допомагає. MySQL, швидше за все, буде добре, якщо "багато" означатиме кілька сотень. (Хоча це залежить від того, що ще має працювати у вашій базі даних. Найбільше, ймовірно, має працювати декілька тисяч.)

Зрештою, це не так вже й важливо, якщо ви пишете ці записи, щоб залишити їх або видалити через кілька секунд до хвилин. Видалення просто робить дві операції з однієї. І MySQL точно може обробляти дуже велику кількість створення та видалення записів. Переконайтеся, що ви використовуєте простий індекс, щоб знову знайти ці записи для видалення.

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

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

Не впевнений, але є варіанти встановити MySQL, які дозволять йому повністю кешувати таблицю в пам'яті. Це все одно в багатьох ситуаціяхі, швидше за все, вам не доведеться багато змінювати. Але якщо ви говорите про дійсно дуже велику кількість користувачів та записів, можливо, ви можете налаштувати кілька параметрів, щоб оптимізувати кешування під ваші особливі потреби.

Ось шалена ідея. Він передбачає припущення та не завжди рекомендовані практики (наприклад, оновлення ключа) - я отримаю багато негативів щодо того, щоб запропонувати це, але ось це іде ...

Якщо припустити, що у вас дуже великий обсяг рядків і великий об'єм видалень, ви можете підвищити продуктивність видалення, створивши на своєму столі два розділи. Розділи відрізнятимуться першою цифрою ключа. Приклад:

Ключове значення 1123234441 призначене для активних рядків, а значення ключа: 9123234441 - для неактивних рядків (перша цифра в цьому прикладі використовується таким чином: 1 = активна, 9 = неактивна).

Тепер, коли користувач видаляє рядок, ви фізично не видаляєте рядок, ви оновлюєте ключ (Ой!), Це автоматично перемістить рядок у неактивний розділ рядків.

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

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

Щоб покращити свій вибір, використовуйте належну індексацію та для покращення вставок мінімізуйте розмір рядка та кількість індексів (цей вислів дуже загальний ...)

Для ознайомлення див .: http://dev.mysql.com/doc/refman/5.1/en/partitioning-types.html Сподіваюся, що це допомагає.