Pull to refresh

Comments 32

Всего один минус и целых три плюсов, по-моему топик субъективен.
Скажем не будет ли медленнее осуществляться горизонтальная выборка? (SELECT * FROM Table WHERE IdType = @Value)
Что будет пониматься под индексацией?

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

Что касается Cassandra, то там, я думаю, такой запрос сделать просто невозможно, если все колонки не лежат в одной column family (тут могу соврать).

В любом случае, индексы не являются «заменой» вертикального хранилища. Это ортогональные понятия. Индексы не позволяют сжимать и секционировать данные.
«Индексы не позволяют сжимать и секционировать данные. „
Секционировать — позволяют. А для сжатия и другие технологии есть, если что (у того же MS SQL, кстати, стратегии сжатия страницы данных вертикаль тоже учитвают).
Сжатие, безусловно, есть. И даже в DB2 пятилетней давности оно было. Но максимально эффективно сжать можно только разделив данные на колонки. Грубо говоря, чем больше разнородных данных мы пытаемся сжать, тем хуже они будут сжиматься.

А как индексы позволяют секционировать ДАННЫЕ?
«Но максимально эффективно сжать можно только разделив данные на колонки.»
Или объединив колонки… никогда не видели таблицу, где значения в колонках скореллированы?

Ну и да, компрессия по колонкам в MS SQL тоже есть. Хотя он горизонтально ориентирован.

«А как индексы позволяют секционировать ДАННЫЕ?»
Во-первых, как я уже писал, с помощью индекса можно вынести часто необходимые данные отдельно от таблицы. Во-вторых, когда нам нужно секционирование по строкам, индексы тоже играют роль.
Компрессия в MS SQL и вообще компрессия в традиционных СУБД вряд ли делает погоду. Другое дело — если используется гибридное хранение данных, т.е. «объединив колонки» на физическом уровне. Делает ли это MS SQL — не знаю.

>можно вынести часто необходимые данные отдельно от таблицы
Это уже будет дублирование данных. По поводу секционирования по строкам — думаю, большинство вертикальных движков это решают даже лучше путем сортировки данных в колонках.
«Компрессия в MS SQL и вообще компрессия в традиционных СУБД вряд ли делает погоду»
Блажен, кто верует.

sqlblog.com/blogs/linchi_shea/archive/2008/05/11/sql-server-2008-page-compression-compression-ratios-from-real-world-databases.aspx

14 произвольно выбранных реальных БД — компрессия от 1.7 до 5.6 раз.

«вряд ли делает погоду», да.
Я не работал много с SQL Server, но судя по описанию его Page Level Compression работает только в пределах страницы и ухудшается при добавлении колонок в таблицу (т.к. при этом все меньше кортежей будет попадать в страницу).

Поэтому с большой вероятностью (тут, конечно, нужны тесты) описанный набор данных при колоночном хранении будет сжиматься гораздо лучше. Кроме того, интересно будет узнать, как это повлияло на пропускную способность SQL Server. В случае DB2 row compression, например, результат не так впечатляет:
When running our DSS workload (consisting of complex queries) a 6% throughput
improvement was observed in the single stream case when using row compression.
«Кроме того, интересно будет узнать, как это повлияло на пропускную способность SQL Server.»
Сжатие данных как бы не ради пропускной способности делается.
Сжатие данных как бы не ради пропускной способности делается.


О как. Ну, возможно в SQL Server это делается ради экономии места на диске стоимостью $500, однако в таких базах как KDB или Vertica компрессия данных является ключевым функционалом, влияющим на пропускную способность СУБД (в том числе за счет более «плотного» заполнения кэша, а также возможности фильтрации сжатых данных). :)
Ну так тогда может быть надо говорить о системах, которые умеют правильно пользоваться компрессией, а не просто о вертикалях или горизонталях?
Нет, не надо :)

Простая комбинаторика говорит о том, что данные, разрезанные по столбцам, сжимаются всегда лучше тех же данных, упакованных в одну строку :) или будет формально правильнее сказать «не хуже»
Вопрос в том, где и как применяется компрессия, вот в чем дело. Сам тот факт, что данные сжимаются «лучше», еще не значит, что от этой компрессии будет выигрыш в пропускной способности.

Про что и речь — если мы хотим получить выигрыш пропускной способности за счет компрессии данных, нам не обязательно нужна база с вертикальным хранением, нам нужна база, которая умеет применять компрессию для решения поставленной задачи.
А смысл?

Проблемы класса «При этом чтобы выбрать, к примеру, имена всех сотрудников, придется сначала прочесть все строки, затем выбросить из них ненужное» решаются правильно построенным индексом, а проблемы класса «чтобы прочитать строчку целиком надо полезть в много разных мест» не решаются никак.
Не совсем понял, причем тут индексы. Вы собираетесь в индекс запихнуть все данные? Индекс обычно содержит указатели на физические страницы данных и позволяет данные фильтровать, однако ну НИКАК не позволит прочесть эти данные с диска быстрее. Даже если пытаться сжимать индексы (что некоторым образом реализовано в BITMAP-индексах Oracle), это не даст никакого эффекта, т.к. сами данные не сжаты.

>проблемы класса «чтобы прочитать строчку целиком надо полезть в много разных мест» не решаются никак

Не всегда и не везде физическое разделение данных плохо. Иногда данные специально размещают в разных местах для лучшей масштабируемости. Запись однозначно дороже, но чтение может обойтись дешевле.
«Вы собираетесь в индекс запихнуть все данные?»
Не все, а те, по которым часто идет выборка.

«Индекс обычно содержит указатели на физические страницы данных и позволяет данные фильтровать, однако ну НИКАК не позволит прочесть эти данные с диска быстрее.»
Если мы выбираем только данные, входящие в индекс, то читать физическую страницу данных просто не надо. Классическая стратегия оптимизации. Более того, то же относится к данным кластерного индекса (потому что они и является указателем). И так далее.
Если запихивать все нужные данные в индекс, то фактически это денормализация, то есть классическая схема-звездочка OLAP.

Тут есть два момента.

  1. Запись становится дороже, а если индексов много — ох как дороже!
  2. Нет компрессии. Вместо уменьшения объема данных мы получили серьезный прирост (ибо данные теперь многократно дублируются). Думаю, не надо объяснять, чем это плохо.


Это уже не говоря о том, что индексы (а именно B-деревья и хэш-таблицы) заточены на поиск и фильтрацию данных, а не на эффективное их хранение.
Любое решение — компромис.

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

Когда вы говорите про «запись индексов дороже», подумайте, сколько будет стоить запись нескольких колонок в вертикально-ориентированной СУБД, при условии, что по ним тоже нужны индексы (поиск-то никто не отменял).
так никто и не спорит.
Если бы вертикальные СУБД были лучше для всех, то все базы давно бы переделали в вертикальные.

>поиск-то никто не отменял
Поиск никто не отменял, только поиск этот немного другой. В вертикальном хранилище гораздо эффективнее можно делать сканирование таблицы по одной колонке и не в пример проще работать с секционированными (partitioned) данными. Поэтому сказать однозначно, что обязательно нужно столько же индексов, сколько в горизонтальной СУБД — нельзя.
Понимаете ли, скан таблицы по колонке — это все равно скан. И на больших объемах все равно будет медленно.
Медленно или медленнее? Скан по сжатым данным и по одной колонке всегда быстрее, чем по всем колонкам.

Касаемо индексов, если интересно, можно почитать, как они устроены в C-Store: C-Store: A Column-oriented DBMS. Там есть понятие Projection, которое приблизительно эквивалентно Materialized View с кластерным индексом. (Projection может быть отсортирован)
«Скан по сжатым данным и по одной колонке всегда быстрее, чем по всем колонкам.»
Это от организации данных зависит, очевидно.
я так не думаю, это тупо зависит от объема данных, который надо прочесть и от их фрагментации
Собственно и объем данных, которые надо прочитать для того, чтобы добраться до нужных, и их фрагментация — зависят от организации этих самых данных.
Если под организацией данных понимается способ их хранения, то да.
>предсказал скорый закат эры классических СУБД;

— быть может он также имел ввиду скорый закат SQL — как сердца классических СУБД (я не имею ввиду полную смерть SQL)? Ведь повернуть прямоугольник на 90 градусов с тем что бы его удобнее было помещать в шкаф или с тем что бы из него удобнее было доставать ложкой содержимое — это ещё не революция… Я сейчас даже не буду предполагать какие СУБД взойдут на горизонт после заката классических: деревянные, кубические… я не знаю. Но мне кажется это будет что-то большее чем поворот на 90 градусов… И быть может стандартный и любимый обеденный прибор (ложки вилки SQL) — будет уже не так удобен…
вертикальные бд нужны для быстрого доступа к таблицам, в которых мало INSERT и много SELECT. я прав? к примеру для хранения названия города и его координаты, оч удобно наверное. Но как же быть с остальными? тем более для быстрой выборки на сколько я знаю при сложных запросах можно использовать к примеру OLAP, пространственную бд. О каком закате эры реляциооных бд может быть после 2D транспанирования? согласен с multic
Мне кажется, гибридное решение Oracle более-менее все эти нужды покрывает. Можно создавать compression unit, можно классические таблицы, можно materialized view. Думаю, в будущем все вендоры внедрят вертикальную схему (как опцию), хотя на это уйдет лет 5, наверное.
На низком уровне данные хранятся в Б-деревьях — уже давно во многих крупных СУБД (тот же оракл). SQL — используется как внешний интерфейс для программистов БД. А таблицы — как относительно-унифицированная структура представлений данных между различными источниками.

Для дерева и куба операция поворота тривиальна — модно укладывать одни данные в столбик, а другие в строку (если мы продолжаем оперировать табличной парадигмой) — как потребуется программисту.

Другое дело, что деревья и кубы предоставляют принципиально новые возможности в работе с данными (а может и со знаниями) но до того как эти возможности и подходы будут повсеместно внедрены, как SQL, пройдёт не один десяток лет — потому что очень многое надо сначала понять — а потом — это понятое зерно посадить в головах… Это не быстрый процесс.

Но какими бы ни были СУБД будущего, мне кажется с профессионального программиста БД не будут сняты такие задачи как проектирование и построение хранилищ данных, OLAP(оперативного анализа), Data Mining(интелектуального анализа), классификации, поиска ассоциативных правил, кластеров и прочего…
> На низком уровне данные хранятся в Б-деревьях — уже давно во многих крупных СУБД (тот же оракл).

Ого. Прямо-таки все данные и прямо в Б-деревьях? Б-дерево не самый удачный формат при большом объеме данных.

> Для дерева и куба операция поворота тривиальна — модно укладывать одни данные в столбик, а другие в строку

Операция, наверное, тривиальна, только с компрессией данных, боюсь, будут проблемы )))
SQL не супер-удачный язык, но вряд ли он умрет в ближайшем будущем — альтернативы ему нет. Стоунбрейкер это прекрасно понимает и свой движок C-Store он делает как SQL-базу.

Что касается революции, то я думаю, что ее не будет. Реляционные СУБД живут уже не один десяток лет и проживут еще долго. А вот сколько видов СУБД уже накрылось — не счесть. Навигационные (типа ISAM), сетевые, объектные…
Смотря что понимать под ближайшим будущим, если 10-15 лет — то точно будет жить, а если 30 — 50 — то далеко не факт.
Only those users with full accounts are able to leave comments. Log in, please.