Кластер из 10 Atom D2700 vs один i7-2600?

Question

[Алексей Помогаев]

Есть огромная БД на MongoDB, из-за большего количества записей время выборки данных не устраивает. Ясно, что нужно делать шардинг. Сейчас это работает на процессоре i7-2600, а шардинг планируется сделать на Atom D2700 (из-за стоимости).


Посмотрел вот такие тесты www.cpubenchmark.net/cpu.php?cpu=Intel+Atom+D2700+... разница в тестах (я пока не разбирался что это за тесты) примерно 12 раз.


Так будет смысл делать шардинг, чтобы получить существенный выигрыш при выборке записей, если заменить один i7 на 10 атомов?


Получается 40 ядер (с учетом HT) и ram 40 Гб, против 8 ядер (с учетом HT) и ram 32 Гб.


Да, выборки идут параллельно, и чем их больше будет параллельно, тем лучше для выигрыша в производительности. Но конечно и время одной выборки может значительно сократиться, если будет на Atom D2700 делаться… Т.е. 100 выборок на i7 без шардинга или делаем 100 выборок на Atom D2700 с шардингом. Что в итоге отработает быстрее и будет ли это в разы быстрее.

Answer 1

[Александр Чекалин]

Я не с ответом, а с просьбой — если все же будете делать, напишите (лучше, конечно, пост) о результатах. Тема уж больно интересная, сам в раздумьях.

Answer 2

[bdmalex]

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

Answer 3

[Пума Тайланд]

А покажите ваш топ с сервера.
Не знаю чего люди странные советы дают без топа.
Не хватает именно проца? Сколько весят базы данных в монге?
На сервере монга одна или ещё что то крутить?

Answer 4

[karellen]

Минусы атомов:
1. Оверхед на систему. На каждой из 10 машин с 4 ГБ памяти, скажем, 500 МБ будет скушано разными системными вещами. 3.5 ГБ памяти для монго даже с небольшой базой — маловато будет.
2. Оверхед на сеть. Хороший гигабитный контроллер прилично нагрузит слабый атом именно сетевой подсистемой.
3. Репликация и бэкапы. Еще 10 атомов? Реплицироваться с шарденой системы на один большой, но тупой сервер, вроде бы, нельзя пока что.
4. У 10 атомов в 10 раз больше шанс чему-то поломаться.
Можно и еще что-то придумать, наверное. Хотя 3 и 4 относятся к любой многосерверной конфигурации, и в реально больших системах с ними просто приходится мириться.

Чисто умозрительно можно посоветовать:
1. Поставить SSD в RAID1 по 250-500 ГБ и базу на них разместить. Читаться будет почти как из памяти.
2. Взять не 2600, а 3930K и добить до 64 ГБ памяти. Реплицировать куда-нибудь послабее.

Comments

[Алексей Помогаев]

>1. Оверхед на систему
Оверхед думаю раза в три меньше должен быть. Обычная консоль, да mongodb демон.

>3. Репликация и бэкапы.
В моём случае это не нужно. Но можно развиртуалить «один большой, но тупой сервер», т.е. сделать 10 виртуалок.

Индексы умещаются в оперативку, к дискам нет обращений.

Answer 5

[demark]

Проясните пожалуйста такой момент: в вопросе вы пишите, что не устраивает время выборки данных, а в комментариях пишите, что все индексы в памяти. Но ведь индекс — это всего-лишь «указатель», в каком блоке на ЖД хранится данные… и считывание всё-равно происходит с ЖД, а это 5-10 ms.

Не думали попробовать хранить данные на SSD? — скорость рандомного доступа ~0.1 ms, что может быть на 2 порядка быстрее ЖД.

Answer 6

[okazymyrov]

А БД лежит на одном диске или на нескольких? Т.е. я хочу сказать, что какая разница сколько будет у вас процессоров, если пропускная способность к БД не измениться. Соответственно производительность будет упираться лишь ширину канала до БД.

Comments

[Алексей Помогаев]

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

[Алексей Помогаев]

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