Организация большой базы данных на кластер NDB

[medval]

Организация большой базы данных на кластере NDB

Здравствуйте! Планируется создание кластера NDB, поступление записей в базу более 100000 в день, прочитал кучу материала и прихожу к выводу что придется раз в месяц добавлять платку с оперативной памятью если не хочу нарваться на переполнения таблиц. Как я понимаю основной параметр отвечающий за пространство, доступное для хранения записей в БД - DataMemory, при дефолтном значении 80М, записей в базу поместилось около 170 000, это максимум на полтора дня работы. Выходит моих 2 гигов хватит примерно месяца на полтора. Кстати с DataMemory я тоже не все понял, а именно, оперативы у меня 2 гига, а при установке этого параметра более 256М получаю ошибку при старте ноды.
Так вот, интересуют собственно 2 вопроса: К правильным ли выводам я пришел по поводу сжирания оперативной памяти движком NDB? И почему не могу выставить в DataMemory более 256М?.Тесты проводил на FreeBSD 6.3, mysql5.1.

 

[флоппик]

Мне интересней, почему ты считаешь, что NDB — это нужное для тебя решение?

 

[medval]

Система у нас заточена под Mysql ну и отказоустойчивость обязательна

 

[whirlwind]

А мне больше интересно, что за данные, если не секрет конечно. Неужели движения фин средств?

 

[medval]

Автор оригинала: whirlwind
А мне больше интересно, что за данные, если не секрет конечно. Неужели движения фин средств?

Что-то в этом роде

 

[флоппик]

Система у нас заточена под Mysql ну и отказоустойчивость обязательна

я все еще не слышу аргументации в выборе NDB?

 

[Gas]

мне тоже хотелось бы услышать аргументы за
и ещё интересно было бы послушать 440hz, об опыте использования кластера.

 

[medval]

Объяснение:
1. Есть биллинговая система, написанная под mysql.
2. Руководство распорядилось сделать данную систему отказоустойчивой.
3. После анализа ничего лучше, чем движок ndbcluster для mysql мы не нашли.
4. "Погоняв" его обнаружили описанные проблемы, но здравый смысл подсказывает, что должно быть адекватное решение для использования ndb, а не бесконечное наращивание оперативной памяти.

 

[флоппик]

3. После анализа ничего лучше, чем движок ndbcluster для mysql мы не нашли.

Х... плохие из вас анализаторы. NDB - это в первую очередь решение на скоростную отдачу. Хоть и отказоустойчивое. Не нужен он вам.

 

[medval]

Автор оригинала: флоппик
Х... плохие из вас анализаторы. NDB - это в первую очередь решение на скоростную отдачу. Хоть и отказоустойчивое. Не нужен он вам.

Хорошо, может тогда хоть 1 дельный совет прибудет?
На всякий повторяю задачи:
1) Около 100000 записей в сутки и около 200000 запросов, возможность держать базу размером около 100GB.
2) Требуется отказоустойчивость.
3) Это должен быть MySQL.

 

[Gas]

1) Около 100000 записей в сутки и около 200000 запросов, возможность держать базу размером около 100GB.

эти цифры не очень пугают и innodb вполне можно использовать, а запрос запросу рознь.

Требуется отказоустойчивость.

в этом вопросе я не гуру, но для начала поизучал бы возможность репликации мастер + пара слейвов, c переключением слейва в режим мастера при падении главного.

p.s. мне казалось что ndb уже может данные держать не только в памяти но и на диске, а может это я какой-то roadmap читал по его развитию.

во, нашёл - http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-roadmap.html

Начиная с 5.1.23:
- MySQL Cluster Replication
- Disk Data storage
- Variable-size columns
- User-defined partitioning
- Autodiscovery of table schema changes
- Online adding and dropping of indexes

 

[флоппик]

Gas, ок, может ты обьяснишь, зачем тут именно NDB тогда?

1) Около 100000 записей в сутки и около 200000 запросов, возможность держать базу размером около 100GB.
2) Требуется отказоустойчивость.
3) Это должен быть MySQL.

Для этого НЕ НУЖЕН NDB. Если этот совет для вас не является дельным, больше мне сказать нечего.

-~{}~ 21.11.08 20:53:

Если у вас готовая система - вы НЕ ПЕРЕВЕДЕТЕ ее на NDB просто так. Если вы не писали, заранее планируя использовать NDB, вы с большой вероятностью ПОТЕРЯЕТЕ в производительности системы.

Мне просто кажется, что вы не знаете, что есть NDB

 

[Gas]

Gas, ок, может ты обьяснишь, зачем тут именно NDB тогда?

не объясню, выбор (мопед) не мой, тем более с ndb сам не работал да success stories особо не слышал (телеком. компании с нереальными бюджетами не в счёт).
А это уже заставляет задуматься, почему известные highload проекты не используют эту технологию.

 

[440hz]

у нас 20 декабря старт проекта. NDB работает. Под наши требования полне подходит.

тлко у нас:

1. расширяемая и отказоустойчивая система при выходе одной ноды
2. 10 лям. хитов в сутки.

собстенно задача у меня чуть другая и тут как раз NDB катит, т.к. при возрвстании нагрузок лепим +2 ноды, расширяем клстер (по необходимости) и систма расширилась, балансировщик ноды подхватил и понеслось. все довольны.

если что конкретное по кластеру - пиши. ответим чем можем. =)

 

[MiksIr]

Хайлоад не использует NDB потому что у того сильно ограничены возможности SQL. Не физически, а по производительности. Самый оптимальный режим использования NDB - выборка по ключу с указанием выбираемых значений (без использования функций). Лучше всего по праймари. Вся чуток усложненная бизнес-логика ставит крест на всей производительности NDB.
Если у людей простые апдейты и простые селекты - возможно NDB будет неплохим вариантом. Если сложные выборки - то мастер-слейв репликация будет более удобна.

-~{}~ 04.12.08 20:49:

440hz, э.. т.е. под боевой нагрузкой еще не проверяли?

 

[Gas]

MiksIr
не спора ради, но имхо, в хайлоаде не часто и используются хитрые возможности sql, чем проше - тем лучше. Но с ndb действительно нужно многое keep in mind из-за производительности, специалистов не так много, в общем ссыкотно как-то
Ну вот теперь 440hz
поделится впечатлениями после запуска и реальной нагрузки.

 

[440hz]

440hz, э.. т.е. под боевой нагрузкой еще не проверяли?

я под лимоном смотрел. даже не напрягается на 2-х нодах. ну так. процентов на 15%. а больше мне пока не взять нагрузку.

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