Что DB для больших баз данных?
Надлежащий путь, по моему скромному мнению, состоит в том, чтобы сохранить список в символьной строке (ограниченный в длине какой поддержка DBMS); единственный прием - то, что (для упрощения обработки) у меня есть разделитель (запятая в моем примере) вначале и в конце строки. Идея состоит в том, чтобы "нормализовать на лету", превратив список в таблицу на один столбец, которая содержит одну строку на значение. Это позволяет Вам поворачиваться
в (ct1, ct2, ct3... ctn)
в
в (выбор...)
или (решение, которое я, вероятно, предпочел бы), регулярное соединение, если Вы просто добавляете "отличное" для предотвращения проблем с дублирующимися значениями в списке.
, К сожалению, методы для разрезания строки являются довольно определенными для продукта. Вот версия SQL Server:
with qry(n, names) as
(select len(list.names) - len(replace(list.names, ',', '')) - 1 as n,
substring(list.names, 2, len(list.names)) as names
from (select ',Doc,Grumpy,Happy,Sneezy,Bashful,Sleepy,Dopey,' names) as list
union all
select (n - 1) as n,
substring(names, 1 + charindex(',', names), len(names)) as names
from qry
where n > 1)
select n, substring(names, 1, charindex(',', names) - 1) dwarf
from qry;
версия Oracle:
select n, substr(name, 1, instr(name, ',') - 1) dwarf
from (select n,
substr(val, 1 + instr(val, ',', 1, n)) name
from (select rownum as n,
list.val
from (select ',Doc,Grumpy,Happy,Sneezy,Bashful,Sleepy,Dopey,' val
from dual) list
connect by level < length(list.val) -
length(replace(list.val, ',', ''))));
и версия MySQL:
select pivot.n,
substring_index(substring_index(list.val, ',', 1 + pivot.n), ',', -1) from (select 1 as n
union all
select 2 as n
union all
select 3 as n
union all
select 4 as n
union all
select 5 as n
union all
select 6 as n
union all
select 7 as n
union all
select 8 as n
union all
select 9 as n
union all
select 10 as n) pivot, (select ',Doc,Grumpy,Happy,Sneezy,Bashful,Sleepy,Dopey,' val) as list where pivot.n < length(list.val) -
length(replace(list.val, ',', ''));
(Конечно, "центр" должен возвратить столько же строк сколько максимальное количество объектов, которые мы можем найти в списке)
14 ответов
У меня без проблем были таблицы в MS SQL Server с более чем 2 миллионами строк. Конечно, это зависит от того, как вы используете эти данные.
Только не пытайтесь использовать MySQL для чего-то вроде этого. По крайней мере, по моему опыту, он просто не позволяет настраивать достаточно, чтобы обеспечить достаточно высокую производительность. Я встречал несколько случаев с большими объемами данных в (почти) идентично настроенных таблицах. MySQL5 работал примерно в 30 раз медленнее, чем SQL Server на том же оборудовании. Возможно, крайний пример, но все же.
У меня слишком мало опыта работы с PostgreSQL или Oracle, чтобы судить, поэтому я просто не буду рекомендовать MySQL. Или доступ;)
Помните, что если у вас большой объем данных:
- индексирование столбцов, в которых вы объединяете таблицы, ОСОБЕННО важно
- , написание эффективных запросов может иметь огромное значение
- , если вы все время запрашиваете данные и редко пишете новые строки, вы можете создавать кластерные индексы и материализованные представления для более эффективного извлечения данных в зависимости от того, какие запросы вы используете чаще всего
Правильно настроенные строки 2MM не имеют большого значения для большинства коммерческих БД и могут не подходить для БД с открытым исходным кодом - я недостаточно знаю о MySQL и др., Чтобы составить мнение .
Под SQL я предполагаю, что исходный плакат означает MS SQL Server. Хотя в выпуске 2000 года были некоторые проблемы с масштабированием, они, похоже, были решены в основном в 2005 и 2008 годах. У меня есть одна testdb, которая имеет значительно больше 2-х миллиметровых строк и работает довольно хорошо.
С уважением, я думаю, что вопрос плохо сформулировано - вам нужно описать гораздо больше информации, чтобы получить полезный ответ. Размер базы данных, количество таблиц, количество общих объединений, будет ли она оптимизирована для чтения, записи или того и другого, количество одновременных пользователей, которые будут поддерживаться, репликация, географическое расположение конечных пользователей по сравнению с сервером базы данных, конфигурация оборудования.
В целом я обнаружил, что SQL Server после 2005 года во многих случаях работает очень хорошо. Если вам нужна возможность настроить все на самом низком уровне, и Oracle, и DB2 предоставят вам лучший доступ и документацию для этого.
Если вам в первую очередь нужно хранилище данных и у вас есть деньги, я бы посмотрел на Neteeza или Teradata. Я фанат Новой Зеландии, но мы партнеры, поэтому я предвзято.
Надеюсь, что это поможет,
Теренс
Попробуйте взглянуть на другие крупные организации, чтобы узнать, что они используют. Доказательством концепции MS для очень больших баз данных является TerraServer , на котором работает база данных размером в несколько терабайт.
Любая база данных будет иметь проблемы с небольшим набором данных, если вы выполняете сканирование таблиц, декартовых продуктов , дорогостоящие вычисления для каждой строки и т. д.
Чтобы по-настоящему нагружать реляционную базу данных таблицей из 2 миллионов строк, вам придется делать перекрестные вкладки, выполняя большое количество вставок и обновлений, и тогда вы захотите для переключения на хранилище данных olap.
У вас есть что-нибудь еще, чтобы описать ожидаемую рабочую нагрузку? Это в основном только чтение, чтение, запись и т. Д.?
Для большинства приложений MS SQL будет работать нормально. MySQL будет работать для небольших приложений, но чтобы ответить на ваш вопрос, если вы действительно обеспокоены производительностью БД, я бы выбрал Oracle, если вы можете себе это позволить, но если вы похожи на большинство из нас, кто не может использовать базу данных за 80 000 долларов, я бы предложил MS SQL Работает хорошо. Судя по тому, что вы делаете (веб-сайт), я бы использовал MS SQL и кеширование. Правильное использование базы данных имеет тенденцию быть более важным, чем использование правильной базы данных.
Microsoft SQL Server, MySQL, Oracle и DB2 могут без проблем обрабатывать миллионы и миллионы строк.
Проблема будет в том, чтобы найти администратора баз данных, который знает, как правильно спроектировать и управлять им, чтобы вы получили требуемые рабочие характеристики.
Как говорили другие, любая достойная БД может справиться с такой нагрузкой. Раньше я использовал MS SQL Server и PostgreSQL для баз данных такого размера, оба отлично работают. Я бы порекомендовал PostgreSQL, потому что он бесплатный и открытый. Я никогда не сравнивал производительность, но, похоже, это очень хорошо. Я бы избегал DB2 или Oracle, потому что их очень сложно использовать (если вы не хотите платить за штатного администратора баз данных, и в этом случае такой человек может выжать из них лучшую производительность, чем любое другое решение, особенно с Oracle).
Я согласен с richardtallent. Все известные системы баз данных предоставили нам хорошие инструменты для больших баз данных. (2 миллиона строк - ничто, хотя вы можете увидеть проблемы с производительностью с паршивыми индексами или плохим выбором в операторах select, особенно если вы объединяете несколько таблиц одинакового размера.). Все сводится к плюсам и минусам, связанным с затратами, удобством использования, стоимостью поддержки и т. Д.
Я больше всего могу говорить с Oracle и SQL Server. Oracle стоит довольно дорого, и для правильного использования требуется дорогостоящий специализированный администратор баз данных. Это н' t известен удобством использования, но администратор баз данных или программист, знакомый с ним, может отлично с ним работать. Он также обладает большой гибкостью, и некоторые считают, что он более мощный, чем другие. (Я не знаю, правда это или нет, но я знаю, что он определенно предоставляет множество различных способов настройки для повышения эффективности и т. Д.)
SQL Server, безусловно, отлично справляется с большими наборами данных. У него «красивее» лицо, и его обычно считают более удобным, но удобство использования, в конце концов, является вопросом мнения. У него более низкая цена, но у вас может быть немного меньше гибкости, чем у Oracle. Вы можете получить "дешевую" базу данных SQL Server, потому что ее удобный интерфейс позволяет людям легко выполнять некоторые из основных задач DBA, не будучи экспертами. Но вы получаете то, за что платите (обычно), и если вам действительно нужна эффективность и безопасность, вы все равно платите за эксперта.
Это лишь некоторые из вещей, которые следует учитывать при просмотре БД. Я уверен, что у MySQL и DB2 есть свои плюсы и минусы, которые нужно взвесить.
Но ни у кого из них нет проблем с жалкими 2 миллионами строк. (Я регулярно работаю с базой данных с сотнями таблиц, некоторые из которых содержат более 50 миллионов строк, и я вижу небольшое снижение производительности, потому что администраторы баз данных знают, что они делают.)
ПОСЛЕДУЮЩИЕ РЕДАКТИРОВАНИЯ: Поскольку это для веб-сайт, возможно, вам больше всего следует подумать об интеграции передней / задней части. Например, если вы используете ASP для Интернета, SQL Server - естественный выбор.
(Я регулярно работаю с базой данных с сотнями таблиц, некоторые из которых содержат более 50 миллионов строк, и я вижу небольшое снижение производительности, потому что администраторы баз данных знают, что они делают.)ПОСЛЕДУЮЩИЕ РЕДАКТИРОВАНИЯ: Поскольку это для веб-сайт, возможно, вам больше всего следует подумать об интеграции передней / задней части. Например, если вы используете ASP для Интернета, SQL Server - естественный выбор.
(Я регулярно работаю в базе данных с сотнями таблиц, некоторые из которых содержат более 50 миллионов строк, и я вижу небольшое снижение производительности, потому что администраторы баз данных знают, что они делают.)ПОСЛЕДУЮЩИЕ РЕДАКТИРОВАНИЯ: поскольку это для веб-сайт, возможно, вам больше всего следует подумать об интеграции передней / задней части. Например, если вы используете ASP для Интернета, SQL Server - естественный выбор.
Во-первых, миллион записей - это не совсем много, когда речь идет о базах данных. Любая достойная база данных должна справиться с этим безупречно.
Создайте правильные индексы для своих таблиц, и почти любая база данных сможет обрабатывать такое количество записей. Я видел базы данных MySQL с миллионами строк, которые прекрасно работали, а MySQL не является тяжеловесом в мире баз данных.
Сервер MS SQL PostgreSQL, DB2, Progress OpenEdge, почти все, что угодно, подойдет, если вы создадите правильные индексы. Такие вещи, как MS Access (и, возможно, sqlite), могут развалиться, если вы поместите в них много данных.
Мы запускаем множество баз данных с количеством строк в сотни миллионов в MSSQL (2000, 2005, 2008). Счетчик строк заключается не в том, где возникнет проблема, а в характеристиках доступа к данным. В зависимости от того, как это выглядит, вам может потребоваться масштабирование на отдельном оборудовании, и именно здесь действительно проявятся различия между серверами баз данных (это и цена ...)
Одна из таблиц в моем текущем проекте содержит 13 миллионов строк. MS SQL Server прекрасно справляется с этим. На самом деле 2 миллиона строк - это ничто.
Но если серьезно, если вам нужна база данных высокого класса, обратите внимание на Oracle, Teradata и DB2.
Нет базы данных, которая называла бы себя базой данных SQL, если бы у них были проблемы с 2 миллионами записей. Однако у вас могут возникнуть проблемы с некоторыми базами данных с 2 миллиардами записей.
У меня без проблем были базы данных mysql с более чем 150 миллионами записей. Вам нужно выяснить, какие функции вам нужны в базе данных, прежде чем принимать решение, а не размышлять над несколькими миллионами строк - это совсем немного.
2000000 строк - это совсем немного. Я видел множество таблиц с> 50 миллионами строк с приемлемой производительностью в MS SQL.
ИМХО, вы все еще очень далеки от «большой базы данных»
Как многие люди уже сказали, такое количество записей не является проблема, если дизайн вашей базы данных выполнен правильно.
Но, возможно, стоит рассмотреть еще один аспект. Сколько пользователей, а именно сколько одновременных пользователей, вы ожидаете от вашего приложения? Если вы ожидаете получить много пользователей, вам также необходимо учитывать масштабируемость ядра базы данных или дизайн базы данных.
Служба MSSql может быть недорогой для настройки одного сервера, но если вам нужно масштабировать, например, запускать на 4 процессорах, лицензирование становится очень дорогим. И когда вы превысили лимит одного сервера, и вам нужно масштабировать до нескольких серверов, что вы делаете? У меня нет ответа на этот вопрос, за исключением того, что, насколько мне известно, MS SQL Server напрямую не поддерживает балансировку нагрузки.
Просто мысль