Работа с много големи данни с mysql

Може ли MySQL разумно да изпълнява заявки за милиарди редове? -- MySQL може да "работи" с милиарди редове. „Разумно“ зависи от запитванията; да ги видим.

InnoDB (MySQL 5.5.8) правилният избор ли е за няколко милиарда редове? -- 5.7 има някои подобрения, но 5.5 е доста добър, въпреки че е почти 6 На 8 години и на ръба на вече не се поддържа.

Най-доброто хранилище на данни за милиарди редове – ако имате предвид „Engine“, тогава InnoDB.

Колко голяма може да стане една MySQL база данни, преди производителността да започне да се влошава - Отново, това зависи от заявките. Мога да ви покажа таблица от 1K редове, която ще се разтопи; Работил съм с таблици с милиард редове, които бръмчат.

Защо MySQL може да е бавен с големи таблици? -- сканирането на диапазона води до I/O, което е бавната част.

Може ли Mysql да обработва таблици, които ще съдържат около 300 милиона записа? -- пак да. Ограничението е някъде около трилион реда.

(за таблици InnoDB, какъвто е моят случай) увеличаване на innodb_buffer_pool_size (например до 80% от RAM). Освен това открих някои други настройки за настройка на производителността на MySQL тук в блога на Percona -- да

като имате правилни индекси в таблицата (използвайки EXPLAIN за заявки) - добре, нека ги видим. Има много грешки, които могат да бъдат направени в това критично област.

разделяне на таблицата -- "Разделянето не е панацея!" Разказвам за това в моя блог

MySQL Sharding -- В момента това е DIY

MySQL клъстериране - В момента най-добрият отговор е някаква базирана на Galera опция (PXC, MariaDB 10, DIY w/Oracle). „Групова репликация“ на Oracle е жизнеспособен претендент.

Разделянето на дялове не поддържа FOREIGN KEY или "глобален" UNIQUE .

UUID, в мащаба, за който говорите, не просто ще забавят системата, но всъщност ще я убият. UUID от тип 1 може да е заобиколно решение.

Скорост на вмъкване и изграждане на индекс – Има твърде много вариации, за да се даде един единствен отговор. Нека видим вашия ориентировъчен CREATE TABLE и как възнамерявате да подадете данните.

Много присъединявания -- "Нормализирайте, но не прекомерно нормализирайте." По-специално, не нормализирайте дати, времена или плаващи числа или други „непрекъснати“ стойности.

Създайте обобщени таблици

2,3 милиона транзакции на ден -- Ако това са 2,3 милиона вмъквания (30/сек), тогава няма голям проблем с производителността. Ако е по-сложно, тогава може да са необходими RAID, SSD, пакетиране и т.н.

се справят с такъв обем данни - Ако по-голямата част от дейността е с "последните" редове, тогава buffer_pool ще "кешира" дейността, като по този начин избягва I/O. Ако дейността е "случайна", тогава MySQL (или който и да е друго) ще има проблеми с I/O.

Свиването на типовете данни помага в таблица като вашата. Съмнявам се дали имате нужда от 4 байта, за да посочите fuel_type . Има множество 1-байтови подходи.