Новая тема   Ответить

 bleed
сейчас пишу одну софтину обрабатывающюю большое колличество информации и сохраняющей результаты в базу.
После первых опытов прикинул что количество записей в одной таблице будет около 10 млн. вытянет ли это мускуль?
никогда не работал с базами где количество записей было больше 100тыс.
а тут 10 млн...

 Formator
Всё ещё зависит от типа инфы в базе. Если там "Война и Мир" в каждой записи - однозначно загнётся. А если там будут обычные поля (строковые, числовые) - почему бы и не работать.

Загибается обычно при дальнейшей работе с базой - при различных выборках и т.п.

Напиши подробнее конфиг сервера (важнее всего объем памяти) и что будет храниться в записях.

 samedi
Зависит от содержимого, как уже было сказано выше.

Ещё более, наверное, зависит от правильности работы с БД. Продуманности использования ключей и индексов.

Выдержит ли технически? Вполне.

 taj
bleed писал: а нормализация какая-нибудь есть? может там дубляжа информации половина будет.
А так samedi: правильно сказал, всё должно тянуть.

 Pentarh
Инна потянет (иннодб). Нормализуй только хорошо.

МайИсам тоже потянет, но там блокировки на уровне таблицы, т.е. таблица будет курить когда пойдет блокирующий апдейт, делит или джойн. Таблица начнет курить, остальные треды начнут виснуть. Количество висюков дойдет до max_connections и остановится. Если это число небольшое, то выживет. Иначе RIP.

Ставь серверу concurrent_insert=2, легче будет если в эту таблицу что то постоянно пишется.

Ну и если ты ее не нормализуешь, то хоть с инной хоть без, но оно наебнется из-за высокого IOWAIT.

 bleed
всем +5

с нормализацией у меня вроде не все так плохо, не одну базу спроектировал.

Данные в базе в основном числовые, и пару строковых полей varchar(255)

Сервер P43Ghz 1Gb ECC
MySql 4.1.21

Основные запросы SELECT
Insert несколько раз в сутки запуск в ручную но много сразу

 blowzy
зависит от сложности selectов твоих.
оптимизируй базу под них.
если все грамотно сделать, то не загнется даже если данных море там хранить, главное чтобы место на диске хватило

 Stek
у меня при 10кк записях селекты на IP3 1Ghz 512Ram по пол минуты выполнялись, поля все числовые были. Индексы помогали мало. Но ведь работало

 Formator


Может у тебя свопилась тачка, тогда пол минуты - это ещё быстро. Пустой мускуль по дефолту жрёт ~400метров, а тут ещё 10лямов записей.

У меня есть база 4млн - довольно сложная выборка делается в среднем 0.003 секунды - всё зависит от памяти ну и от отпимизации - верные индексы, верные типы полей ну и конфиг мускуля конечно же надо тюнить.

А ИнноДБ как раз таки слетает очень быстро при интенсивной работе с ней, в отличае от майисама. Может у меня у одного так - не знаю, но юзаю майисам.

 Stek
у меня с innodb не сложилось. Пухнет, если вылетит - рековери нет.

 Pentarh
Stek писал:
Надо юзать log-bin

Тогда автоматом рековерится

 Силверсторм
покури книгу - mysql поля дюбуа, там хорошо моменты оптимизации описаны. например если у тебя в поле varchar(255) данные не всегда достигают 255 длинны то разумнее будет использовать статическую char(255) - разница в том что варчар принимает динамическое значение равное количеству данных, но при выборках работает медленнее чем чар() который занимает указанное количество байтов не смотря на то что строка с данными может быть короче.

вобщем там таких моментов много - сам недавно с помощью этой книги у себя софт оптимизировал в котором сейчас 5млн записей почти. работает довольно шустро - 5000к случайных записей отдает за 0.11 секунд что для меня довольно приемлимо.

плюс конечно почитай про конфигурацию самого мускуля /etc/my.cnf там тоже може многое улучшить.