Здравствуйте, Sinclair, Вы писали:

V>>Ошибку сейчас совершил ты — имеется ввиду отношение объемов индексов и RAM.
V>>С древовидными индексами и размерами RAM всё было хорошо в течении нескольких десятилетий, бо рост основного дерева индекса логарифмический от роста кол-ва данных, а размеры RAM росли быстро.
S>Что такое "основное дерево индекса"? Есть ещё второстепенные деревья?

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

То бишь, оценка размера деревянного индекса может быть как log(N), так и log(N) + N.

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


S>Что такое "рост дерева"?

Действительно, что такое рост? ))


S>Кстати, вопрос про n-tree из соседнего треда всё ещё в силе. Вместе с вопросом про индексы time series

Мы это уже обсуждали.
В 1С неплохо покрыто.

Есть валюты, есть даты изменений валют, тебе надо делать join по датам от таблицы операций на таблицу курсов валют, а в той содержатся, допустим, только даты изменений курса, но не курс на каждый день.


S>и вероятностные индексы.

Мы это тоже уже обсуждали — которые имеет смысл перестраивать от статистики, инфы более чем полно.


S>Мне такие вещи интересны, всегда готов узнать что-то новое в любимой области.

Ничего нового в этой области давным давно нет.
По крайней мере в теории.
В реализации, может, сопли какие подберут, шероховатости причешут и т.д.
Но это не "новые концепции", это убожество в плане такой вещи как развитие.

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

Просто в этом примитивном сценарии NoSql серваки надирали "традиционным" реляционкам попку как младенцам, те теряли лицо.
Ну а больше-то и вспомнить нечего...

Развитие реляционных СУБД в последние годы

V>>Просто надо понимать специфику — сейчас в среднем "реальных данных" всё еще столько, что обычный b-tree индекс справляется на ура.
S>Не, нужно знать факты. Если бы "обычный b-tree индекс" справлялся на ура, никто бы не задурялся разработкой compressed b-tree индексов.

V>>Но появилась новая отрасль — биг дата.
S>Что удивительно, основные статьи по компрессии индексов были опубликованы за десятилетия до появления термина big data.

Здравствуйте, Sinclair, Вы писали:

V>>Ошибку сейчас совершил ты — имеется ввиду отношение объемов индексов и RAM.
V>>С древовидными индексами и размерами RAM всё было хорошо в течении нескольких десятилетий, бо рост основного дерева индекса логарифмический от роста кол-ва данных, а размеры RAM росли быстро.
S>Что такое "основное дерево индекса"? Есть ещё второстепенные деревья?

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

То бишь, оценка размера деревянного индекса может быть как log(N), так и log(N) + N.

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


S>Что такое "рост дерева"?

Действительно, что такое рост? ))


S>Кстати, вопрос про n-tree из соседнего треда всё ещё в силе. Вместе с вопросом про индексы time series

Мы это уже обсуждали.
В 1С неплохо покрыто.

Есть валюты, есть даты изменений валют, тебе надо делать join по датам от таблицы операций на таблицу курсов валют, а в той содержатся, допустим, только даты изменений курса, но не курс на каждый день.


S>и вероятностные индексы.

Мы это тоже уже обсуждали — которые имеет смысл перестраивать от статистики, инфы более чем полно.


S>Мне такие вещи интересны, всегда готов узнать что-то новое в любимой области.

Ничего нового в этой области давным давно нет.
По крайней мере в теории.
В реализации, может, сопли какие подберут, шероховатости причешут и т.д.
Но это не "новые концепции", это убожество в плане такой вещи как развитие.

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

Просто в этом примитивном сценарии NoSql серваки надирали "традиционным" реляционкам попку как младенцам, те теряли лицо.
Ну а больше-то и вспомнить нечего...


V>>Просто надо понимать специфику — сейчас в среднем "реальных данных" всё еще столько, что обычный b-tree индекс справляется на ура.
S>Не, нужно знать факты. Если бы "обычный b-tree индекс" справлялся на ура, никто бы не задурялся разработкой compressed b-tree индексов.

Вылизыванию нет границ.
Но ускорение в разы за счёт вполне себе инженерных практик vs изменение сложности в терминах O за счёт изобретения новых алгоримтов — разные вещи.


V>>Но появилась новая отрасль — биг дата.
S>Что удивительно, основные статьи по компрессии индексов были опубликованы за десятилетия до появления термина big data.

1. Компрессия данных — это инженерное решение, выдуманое раньше. Т.е. отсутствует формула изобретения.
2. Опять ты порешь эту чушь про РСУБД в 60-х.
3. За десятилетие до появления big data сами РСУБД только 5 лет как существовали во вменяемом исполнении.

Но ты пенял на "глупых программистов прошлого", что они не напомнили тебе из 60-х годов, что в будущем появятся СУБД и в них тоже можно будет хранить данные с компрессией!!!
Только не забудьте что компрессию в СУБД использоваться тоже можноооо... (эхо, эхо)...

Ладно, поржал, спасибо.
Такое невменяшко... ))