LINUX.ORG.RU
Форум — Web-development  

Огромные БД на MySQL

 ,


1

1

Коллеги, поделитесь, пожалуйста, опытом администрирования и работы MySQL баз объемом более 1 Гига. Скажем, БД размером в 25 Гигов или даже 100. Я никогда с ними не сталкивался, но хотелось бы узнать как с таким объемом можно работать. Насколько падает производительность и, вообще, имеет ли смысл делать базы такого объема на MySQL?

← Ajax PHP - Как лучше возвращать результат?
private image hosting with API →

опытом администрирования и работы MySQL баз объемом более 1 Гига.

Есть БД MySQL 5 Гб. Опыт администрирования связан не только с размером, но и со сложностью БД. Приходится очень аккуратно писать запросы, чтоб а разумное время получить результат.

Насколько падает производительность

Зависит от того насколько грамотно спроектирована БД. В идеальном случае при увеличении БД в 10 раз производительность падает в 2 раза.

King_Carlo ★★★★★
()

Огромные БД на MySQL
объемом более 1 Гига. Скажем, БД размером в 25 Гигов или даже 100.

гм, это совсем не «огромные» и даже не «большие».
у меня даже вордпресс базой больше гига ворочает спокойно

xtraeft ★★☆☆
()

40Г x полмиллиарда записей.

В начале года кажись 25 было. Вроде никакой разницы. Никто не жаловался.

ziemin ★★
()

Скажем, БД размером в 25 Гигов или даже 100

Не размер, сначала прочитал невнимательно, показалось Тб :)

aeX1pu2b ★
()
Ответ на: комментарий от xtraeft

Дорвейчики? Это же чудесно :) А я в эту тематику не лезу - боюсь, паранойю.

coderage ★
()

Да пофигу. Все зависит от хорошо продуманной структуры.

soomrack ★★★★★
()

когда база dbmail стала 100Г пришлось добавить 4Г озу

sergej ★★★★★
()

почитать, что такое индексы. если знаешь и умеешь ими пользоваться то 1, 5, 10 гигов для бд это не объемы. проблемы возможны начиная от 100 гигов или таблиц с 1.000.000+ записями (на современном железе).

vtVitus ★★★★★
()

С точки зрения производительности чем больше база, тем сильнее сказывают архитектурные косяки. Например может появится такой инцидент как вымывание кеша, каким либо запросом. Ибо раньше он выбрал мегабайт 300 и успокаивался, а теперь выбирает 8Гб и опаньки.

С точки зрения администрирования, чем больше база тем сильнее нужен бэкап без останова БД, то есть есть смысл думать о как о реплике, с которой снимать бэкап, так и о самом способе снятия бэкапа. Пользоваться sqldump-ом на больших объемах быстро «надоедает».

TEX ★★★
()

:-] есть же оракель

anonymous
()

Суть не в размере бд, а размере отдельных табличек.

anonymous
()
Ответ на: комментарий от TEX

С точки зрения производительности чем больше база, тем сильнее сказывают архитектурные косяки.

++

soomrack ★★★★★
()
Ответ на: комментарий от stevejobs

Во-первых, 25-100Гб не те объемы, чтобы использовать Hadoop, этого слишком мало. Во-вторых, Hadoop не РСУБД, он не подходит для таких задач. HBase тут тоже не подойдет, т.к. больше предназначен для работы с Hadoop. Да и вообще использование всякие MR и BigTable на объемах меньше пары сотен Тб весьма сомнительно.

xpahos ★★★★★
()
Ответ на: комментарий от TEX

Один из методов бэкапа огромной базы (у нас, например, более 500 гигов) - держать отдельный слейв, не критичный по отставанию. Догнали мастер, остановили в нужный момент, сделали бэкапы, включили дальше.
У нас этот слейв утром останавливается, вечером опять влючается. Пару раз выручал, когда с продакшен-базой днем косячили.

tuxin ★
()
Ответ на: комментарий от tuxin

Я по репликой примерно это и подразумевал. Другой вопрос что, бекап с остановкой слейва и видимо с последующим копированием файлов БД, немного печалит. Нормальная СУБД должна уметь делать свой бэкап без останова БД

TEX ★★★
()
Ответ на: комментарий от xpahos

если на 100Гб от хбазы никакого вреда, почему бы не заюзать хбазу? Потому что она говно? Потому что она сожрет, ужас, на целых 30 процентов больше от ресурсов ноды?

stevejobs ★★★★☆
()

Только postgres, только качественные базы!

elagagarina
()
Ответ на: комментарий от stevejobs

Вреда нет, но это не повод использовать HBase там где он не нужен. Да, это модно, стильно, молодежно, но пихать тот же MR на 1-20 машин, когда с этим справится 1-2 сервера с MySQL и шардингом как-то глупо. 100Гб это очень мало. Сейчас вот ковыряю базу на 18Тб и с ней явно не справится даже Oracle :)

xpahos ★★★★★
()

Ну как-то так вот..

root@db-2:~# du -h --max-depth=1 /data/db/ 410K /data/db/mysql 1,2T /data/db/billing 209K /data/db/performance_schema

root@db-2:~# free -g total used free shared buffers cached Mem: 47 30 16 0 1 3 -/+ buffers/cache: 25 21 Swap: 1 0 1

Самая толстая таблица весит 60 гигов..

QPS примерно 250K в пике и 110К в среднем..

Запросы в основном INSERT и UPDATE .. меньше SELECT но последние очень монструозные..

Да есть реплика с теми же TTX..

Вообще БД сускловое таких размеров это ад..

Valor ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Ajax PHP - Как лучше возвращать результат?
Web-development
private image hosting with API →