SQLinfo.ru - Все о MySQL

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Вы не зашли.

#1 23.02.2011 11:27:49

FaWuS
Участник
Зарегистрирован: 22.12.2009
Сообщений: 5

20 млрд. записей в таблице

Доброго времени суток, всем.
В связи с датой, заодно, всех мужчин с праздником smile

Таблица (InnoDB):

- (BIGINT,18) (PRIMARY, UNSIGNED, AUTO_INC)
- (CHAR,200)
- (CHAR,200)
- (INT,8)
- (INT,8)
- (INT,9)


Добавляться будут данные по ~1 тысяче записей в секунду отдельными запросами* (продолжительность такой нагрузки 8-10 часов в сутки).
По расчётам в течение 3 лет таблица будет иметь порядка 20 млрд. записей.

Данные будут считываться единственным образом:
"SELECT * FROM table WHERE id=1234"

Т.е. будет выбираться строка целиком по PRIMARY.

Считываться данные будут от 1 до 100 тысяч раз в секунду отдельными запросами**
Количество запросов будет расти пропорционально общему количеству записей в таблице.

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

Прошу совета у опытных людей - что необходимо изменить, улучшить или дополнить для оптимального решения задачи?

Неактивен

 

#2 23.02.2011 20:37:10

rgbeast
Администратор
MySQL Authorized Developer and DBA
Откуда: Москва
Зарегистрирован: 21.01.2007
Сообщений: 3880

Re: 20 млрд. записей в таблице

1. Проверьте скорость вставки на Innodb и сравните с MyISAM. Кажется, что MyISAM будет вставлять быстрее.

2. Имеет смысл создавать несколько таблиц. Например, одну таблицу в неделю. В таком случае вставка будет только в последнюю таблицу и не будет затрагивать остальные, которые можно постепенно переводить в COMPRESSED. В отдельной маленькой таблице можно хранить диапазоны id в каждой из таблиц (это можно кэшировать в memcached), таким образом SELECT всегда будет обращаться только к одной таблице.

3. Количество простых выборок в секунду говорит, что удобно будет использовать плагин HandlerSocket.

4. Вставка быстрее без индексов. Если можно последную таблицу формировать без индексов, а потом создавать индекс, то это будет ускорением (вопрос в том, какая будет потеря на селектах). Как вариант - рабочую копию последней таблицы хранить в таблице типа MEMORY, чтобы избежать потерь на полном скане по сравнению с индексным поиском.

Неактивен

 

#3 24.02.2011 01:17:15

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: 20 млрд. записей в таблице

А меня пугает CHAR(200). Кажется, это не осмысленное действие —
использовать 200 байт там, где можно использовать от 1 до 201.

Неактивен

 

#4 24.02.2011 09:23:28

FaWuS
Участник
Зарегистрирован: 22.12.2009
Сообщений: 5

Re: 20 млрд. записей в таблице

rgbeast написал:

1. Проверьте скорость вставки на Innodb и сравните с MyISAM. Кажется, что MyISAM будет вставлять быстрее.

Вставки и выборки будут производиться в перемешку. Боюсь блокирование в MyISAM приведёт к большим затупам, даже если только вставку MyISAM отработает быстрее.

rgbeast написал:

2. Имеет смысл создавать несколько таблиц. Например, одну таблицу в неделю. В таком случае вставка будет только в последнюю таблицу и не будет затрагивать остальные, которые можно постепенно переводить в COMPRESSED. В отдельной маленькой таблице можно хранить диапазоны id в каждой из таблиц (это можно кэшировать в memcached), таким образом SELECT всегда будет обращаться только к одной таблице.

Идея понятная и отличная, спасибо! Есть несколько вопросов:
- Можно ли это реализовать силами MySQL или это делается на стороне?
- После каждой вставки нужно получать присвоенный ID обратно. Как при таком разложении по таблицам это делать? (опять же, если силами MySQL)

rgbeast написал:

3. Количество простых выборок в секунду говорит, что удобно будет использовать плагин HandlerSocket.

Погуглил - похоже отличным дополнением будет.
Большое спасибо!

rgbeast написал:

4. Вставка быстрее без индексов. Если можно последную таблицу формировать без индексов, а потом создавать индекс, то это будет ускорением (вопрос в том, какая будет потеря на селектах). Как вариант - рабочую копию последней таблицы хранить в таблице типа MEMORY, чтобы избежать потерь на полном скане по сравнению с индексным поиском.

Отлично! Можно без индекса. Частота обращений считается большей, чем дольше данные лежат в базе. Т.е. свежедобавленные данные выбираться часто не должны. Тут опять же возникает 2 вопрос - силами MySQL или на стороне?

paulus написал:

А меня пугает CHAR(200). Кажется, это не осмысленное действие —
использовать 200 байт там, где можно использовать от 1 до 201.

Я исходил из соображений, что статическая таблица лучше динамической. Хотя, учитывая, что выборка по CHAR столбцам не будет производиться, возможно действительно стоит сделать их переменными. Спасибо!

Неактивен

 

#5 24.02.2011 23:28:29

paulus
Администратор
MySQL Authorized Developer and DBA
Зарегистрирован: 22.01.2007
Сообщений: 6757

Re: 20 млрд. записей в таблице

Со стороны MySQL разбить таблицу можно с помощью partitioning, но лучше
закладывать также и шардирование в код: оно все равно понадобится, и чем
раньше Вы его заложите, тем больше сил сэкономите вдальнейшем.

Неактивен

 

Board footer

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson