Проектирование баз данных: одна огромная таблица или отдельные таблицы?
это нужно для работы:
import pprint
import time
import os
pretty = pprint.PrettyPrinter(width = 20)
meals = {}
command = ""
condition = False
n = False
if not os.path.isfile('meals.txt'):
f = open("meals.txt", "w+")
f.write(str(meals))
f.close()
else:
n = True
def save_dict_to_file(meals):
f = open("meals.txt", "w+")
f.write(str(meals))
f.close()
def load_dict_from_file():
f = open("meals.txt", "r+")
data = f.read()
f.close()
return eval(data)
if n:
meals = load_dict_from_file()
def add_entry():
meal = input("Enter name of meal: ").lower()
units = int(input("Enter units needed: "))
meals[meal] = units
pretty.pprint(meals)
save_dict_to_file(meals)
import os
def remove_entry():
os.remove('meals.txt')
def help():
pretty.pprint('help')
def view_dict():
pretty.pprint(load_dict_from_file())
def ending_message():
pretty.pprint('done')
while True:
command = input("> ").lower()
if command == "help":
help()
elif command == "add":
add_entry()
elif command == "exit":
save_dict_to_file(meals)
ending_message()
time.sleep(3)
break
elif command == "remove":
remove_entry()
elif command == "view":
view_dict()
13 ответов
Начните с одной большой таблицы, а затем примените возможности 2008 разделения таблиц там, где это необходимо, , если производительность становится проблемой .
Вы также можете создавать дополнительные таблицы, которые содержат уже рассчитанные детали исторической информации, если есть общие запросы.
Если вы работаете на сервере MS SQL и хотите сохранить одну таблицу, разделение таблиц может быть одним из решений.
Одна таблица и разделение таблицы.
Думаю, что совет по использованию NOLOCK неоправдан на основании предоставленной информации. NOLOCK означает, что вы получите неточные и ненадежные результаты ваших запросов (грязное и фантомное чтение). Перед использованием NOLOCK вы должны быть уверены, что это не станет проблемой для ваших клиентов.
Я предполагаю, что ваша база данных правильно нормализована. Не должно быть проблемой иметь дело с объемом данных, на который вы ссылаетесь в одной таблице в SQL Server; я думаю, вам нужно просмотреть ваши индексы.
Хранилища данных должны быть большими (ключ к названию). Двадцать миллионов строк - это, по меркам складских стандартов, средний показатель, хотя шестьсот миллионов можно считать большими.
Следует иметь в виду, что такие большие столы имеют различную физику, например черные дыры. Поэтому настройка их требует другого набора техник. Другое дело, что пользователи хранилища данных должны понимать, что имеют дело с огромными объемами данных, и поэтому они не должны ожидать ответ в секунду (или даже в минуту) для каждого запроса.
Разделение может быть полезным, особенно если у вас есть четкое разграничение, например, как в вашем случае, CUSTOMER. Вы должны знать, что секционирование может ухудшить производительность запросов, которые пересекают структуру ключа секционирования. Так что это не серебряная пуля.
Разделение таблиц по соображениям производительности называется сегментированием . Кроме того, схему базы данных можно более или менее нормализовать. В нормализованной схеме есть отдельные таблицы со связями между ними, и данные не дублируются.
В правильно спроектированной базе данных это не такое уж большое количество записей, и SQl-сервер должен с легкостью с ним справиться.
Разделенная на части единая таблица обычно является лучшим способом. Попытка поддерживать отдельные таблицы клиентов требует больших затрат времени и сил и гораздо больше вероятности ошибок.
Также проверьте текущие запросы, если у вас возникли проблемы с производительностью. Если у вас нет надлежащей индексации (например, индексировали ли вы поля внешних ключей?), запросы будут медленными, если у вас нет больших запросов, они будут медленными, если вы использовали коррелированные подзапросы или курсоры, они будут медленными. Возвращаете ли вы больше данных, чем нужно? Если в вашем производственном коде есть select *, избавьтесь от него и возвращайте только те поля, которые вам нужны. Если вы использовали представления, которые вызывают представления, которые вызывают представления, или если вы использовали таблицу EAV, у вас будут проблемы с производительностью на этом уровне. Если вы позволили фреймворку автоматически генерировать SQl-код, у вас вполне могут быть плохо выполняемые запросы. Помните, что Profiler - ваш друг. Конечно, у вас также могут быть проблемы с оборудованием, вам нужен довольно большой выделенный сервер для такого количества записей. Не получится запустить это на вашем веб-сервере или маленькой коробочке.
Я предлагаю вам нанять профессионального dba с опытом настройки производительности. Это довольно сложная вещь. Базы данных, разработанные прикладными программистами, часто плохо работают, когда в них появляется реальное количество пользователей и записей. База данных ДОЛЖНА быть разработана с учетом целостности данных, производительности и безопасности. Если вы этого не сделали, то шансы на успех действительно невелики.
Поскольку вы пометили свой вопрос как 'datawarehouse', я предполагаю, что вы кое-что знаете о предмете. В зависимости от ваших целей, вы можете использовать схему "звезда" (многомерная модель с таблицами фактов и размерностей). Храните все быстро меняющиеся данные в одной таблице (на предмет), а медленно меняющиеся данные - в других таблицах измерения/"снежинок".
Другим вариантом является метод DataVault Дэна Линдстедта. Он немного сложнее, но обеспечивает полную гибкость.
Сохраняйте одну таблицу - 20 миллионов строк не огромны, а клиенты - не совсем тот тип таблиц, которые можно легко «заархивировать», а агрегация поиска в нескольких таблицах для поиска клиента не стоит усилий (SQL, вероятно, будет намного более эффективным при поиске в BTree, чем ваше собственное изобретение)
Однако вам нужно будет изучить проблемы производительности и блокировки - это предотвратит масштабирование вашего БД.
Одна таблица, затем беспокойтесь о производительности. Это при условии, что вы собираете точно такую же информацию для каждого клиента. Таким образом, если вам нужно добавить/удалить/изменить столбец, вы будете делать это только в одном месте.
Разделение определенно нужно изучить. У меня была база данных, в которой было 2 сегментированных таблицы. Каждая таблица содержала около 30-35 миллионов записей. С тех пор я объединил это в одну большую таблицу и присвоено несколько хороших индексов. До сих пор мне не приходилось разбивать эту таблицу, так как она работает, но я продолжаю разбивать ее в mi nd. Одна вещь, которую я заметил по сравнению с тем, когда данные были сегментированы, - это импорт данных. Теперь он работает медленнее, но я могу смириться с этим, поскольку инструмент импорта можно переписать; o)
Это один плоский стол (без конкретной модели)? Обычно в хранилищах данных у вас либо есть нормализованная модель данных (по крайней мере, третья нормальная форма - обычно в модели отношений сущностей), либо у вас есть размерные данные (метод Кимбалла или вариации - обычно таблицы фактов со связанными таблицами размерности в наборе звезд).
В обоих случаях индексы играют большую роль, и секционирование также может играть определенную роль в выполнении запросов (но секционирование обычно связано не с производительностью, а с возможностью быстрого добавления и отбрасывания разделов) над очень большими наборами данных, но это действительно зависит от порядка агрегирования и типов запросов.