Работа идет по плану, все трудятся (кто-то одноклассничает, не будем останавливаться на этом моменте, главное - все заняты).
Идут дискуссии, совещания, планерки... Незаметно в работе появляется такой этап (наблюдаемый мною на нескольких фирмах), когда или архитектор, или программист баз данных - начинает с сосредоточенным выражением лица подсчитывать... сколько байтиков займет такая вот структура SQL-таблицы...
А у меня сразу вопросы:
1) Разве известен объем дисковых накопителей, на этапе разработки enterprise-проекта, что можно уже "мерять" и "примерять"? Да пока разработка завершится (структура СУБД проектируется отнюдь не в последние дни, обычно - в первый, максимум - во второй месяц разработки) - доступное решение, по емкости, может быть в 1.5 раза выше, чем можно "наблюдать сейчас". Тем более во многие проекты стараются закладывать "переносимость", по СУБД. Т.е. вообще ничего по емкости не известно (в контексте самой задачи).
Кто-то хочет сказать, что уже "есть готовый сервер" под СУБД? А когда он наполнится, данными? Через год, сразу после завершения проекта? Разве? Через 2-3 года, "если проектировать безвольно, не учитывая". Что значит "не учитывая"? Кто ж проектирует, не оптимизируя? Вопрос в том - что значат эти подсчеты? Плавно переходим ко 2-му пункту.
2) Ну, хорошо, система проектируется из расчета - 1.500.000 пользователей. И? Что значат подсчеты? Подсчитывается, обычно, все по нескольким таблицам. На первом месяце разработки. А кто подсчитает ВСЕ ОСТАЛЬНОЕ? Когда бизнес-требования изменятся? Разработка ведь - носит (в наши времена) - в большинстве случаев - итеративный характер. Что можно считать НА ПЕРВОМ МЕСЯЦЕ разработки? Ну вот что?
Это все равно, что на первом месяце разработки - прикидывать, в уме (на листике) - закрома Родины через 4 года. Ну столько факторов, которые могут все увеличить в 2-3 раза, или уменьшить - что просто не передать словами. Цену на нефть кто-нибудь знает, какой она будет через 2 года? И сколько миллиардов инвестируется в отечественный автопром - через 3 года? Точную цифру назвать можете? А, что так? Слабо на листике подсчитать? Достаточно сказать, что колебания курса на рынке Форекс - уже сама по себе нетривиальная функция. На которую нужно опираться, в расчетах.
Так же и здесь. 1.500.000 пользователей в таблицах user_accounts, user_payments и 50 бизнес-требований, которыми вас "наградят" (начальство, аналитики, партнеры) через 3 месяца.
Я понимаю - задать ограничения на максимальную длину отдельных текстовых полей. Но при этом никто не смотрит "сколько байтиков займет". Можно (и нужно) проектировать эффективное приложение. По сотне самых разных факторов и показателей (выбор СУБД, например). Но считать число байт, по какой-то одной или 2-3 таблицам - ммм...
дело не в том, сколько байтиков на диске займет запись в таблице, а в том, сколько байтиков займет результат запроса из этой таблицы в памяти, на сколько одновременных запросов хватит оперативной памяти, и когда ее не хватит и система начнет активно свопиться, при этом снижая производительность в десятки раз. На сколько одновременных запросов хватит сегмента отката - это тоже очень критичный вопрос, т.к. есть разница между откатом ряда транзакций, которые все еще находятся в сегменте отката (эта операция происходит в онлайне, не затрагивая основные процессы) и восстановлением из резервной копии с накатыванием изменений до нужной точки (эта операция требует остановки БД и может занимать от нескольких часов до нескольких суток).
ОтветитьУдалитьЕще один важный нюанс - размер блока данных в БД, который задается один раз при создании БД и не может просто так быть изменен, а этот маленький параметр фактически определяет скорость работы с диском и размер дата-файлов.
Нюансов - множество. Исправлять их потом по факту чрезвычайно непросто (тот же размер блока только путем пересоздания базы/экспорта/импорта данных, т.е. простоя базы в течение нескольких суток).
Также размер записи напрямую влияет на процессы построения и перестроения индексов.
И если с жесткими дисками все более или менее просто решается - можно расширять до бесконечности, то с оперативной памятью и архитектурой самой СУБД все гораздо сложнее.
Конечно современные СУБД, такие как Оракл, не будут забирать память под пустые поля, т.е. используют ее очень эффективно, но это еще не значит, что к размерам полей надо относиться так безалаберно.
К тому же байты считаются как правило в тяжелых таблицах, предполагающих частые обращения, т.е. в таблицах, в которых предполагается иметь несколько миллионов строк и большое количество столбцов (например, 30). Такие таблицы как правило нарочно денормируются. А в таблице, содержащей несколько тысяч строк, совершенно все равно, сколько байт будет в каком поле - никакого падения производительности не будет.
и еще один маленький нюанс - расширить поле в таблице можно в любой момент при помощи ALTER TABLE MODIFY, а вот сузить его, если в таблице, есть хотя бы одна строка с данными, уже не получится, только путем добавления и удаления столбцов с переносом данных
ОтветитьУдалитьЮр, ты все правильно пишешь. Могу сказать вот что:
ОтветитьУдалить1) Для Oracle рекомендуется оставить автоматическое управление памятью (та настройка, которую мы задаем при инсталляции).
2) Администратор Oracle - может выносить какие-то структуры базы данных - в специальные сегменты памяти, чтобы они постоянно оставались в кэше.
3) Размер блока данных - да, есть выбор, задаваемый при инсталляции. Вот тут ты как бы прав. С другой стороны - "нестандартные" размеры блоков - используют только в каких-то особых случаях. Понимаю, что любые разработки под Oracle - можно, с натяжкой, охарактеризовать, как "совокупность нестандартных случаев". К тому же, ко всему этому - вопросы выбора файловой системы (нужны ли кластеры, в том числе). Юр, если вот взять НОВУЮ разработку - то можно ПРИМЕРНО прикинуть - кластера и т.д. И СЛЕДОВАТЬ РЕКОМЕНДАЦИЯМ - потому что может быть "слабонагруженное" приложение (например мне написали в приват про один, готовящийся сейчас проект, с заранее фиксированным числом пользователей в нем). Можно выделить такую специфическую область, как биллинг. Под такие вещи, широко известные - есть набор характеристик/рекомендаций - и, главное тут ;) - байтики никто не подсчитывает при этом... ;)
Кстати, Юр - эта статья - не про "твою" фирму. Возможно я просто не застал тот период, когда ты, возможно, ;) подсчитывал байты. :)
ОтветитьУдалитьНа других двух фирмах такое замечал.