Комментарии 18
Потому что в текущих реалиях этими тематиками тут бесперспективно заниматься (и, соответственно, преподавать).
Во-первых, транзакции невероятно трудно на современном уровне преподать и еще труднее изучать. Предмет сложный -- старые теории вообще граничили с матлогикой (одни кванторы и теоремы), не знаю что там сейчас, правда.
Во-вторых, есть отсутствие "инфраструктуры". Например, по теории транзакций на русском языке нет книг вообще. Или вот сейчас нет и исследовательского сообщества по этой тематике. И, кажется, что всерьез никогда и не было -- я вот так сходу не могу вспомнить ни одной группы которая бы занималась этим на постоянной основе. Да, работы были, но это был штучный товар. Человек ушел -- всё, экспертиза исчезла.
В третьих, студенты крайне не любят изучать вещи, которые они не смогут применить на практике после выпуска. В нашей стране с трудоустройством по этой тематике выбор крайне невелик.
Вот такая ситуация, то есть вопрос не к предмету, а его месту в нашем мире. А так, конечно, материал интересный -- книжка Вейкума и Воссена очень классная (хоть и говорят что устарела уже).
Речь идет не о рассказе про уровни изоляции или про аномалии конкурентного доступа, это все азы касающиеся того, как пользоваться существующими решениями. Я говорю о более глубоком уровне -- разработке новых схем / протоколов или хотя бы имплементации существующих в своих движках.
Что, как ученый, можете сказать про графовые БД?
Графовыми БД я никогда не занимался. И в свободное время я не смог собрать в голове консистентную картину, что же в вокруг них происходит. Кажется, что там много не то что подходов, а много целых "вИдений" насчет того, что важно. Но если бы вдруг всерьез встала задача понять что там, я бы пошел изучать вот этот туториал:
http://www.vldb.org/pvldb/vol11/p2106-deutsch.pdf
Там надо искать видео и слайды, по ссылке просто summary. И, да, если я не ошибаюсь, авторы туториала стоят за TigerGraph.
Ясно :) А я бы порекомендовал вот это недавнее выступление https://vimeo.com/623756277#t=2100s
Огромное спасибо за материал. Именно ради таких статей и стоит читать Хабр. И очень обидно, что так мало «плюсов».
По поводу того, что вас так восхитило, есть определённые сомнения:
Идея этого подхода следующая: заменить классический индекс (пусть, на B-дереве), на иерархию “моделей”, которые будут предсказывать, где лежит ключ.
Всё-таки «модель» – штука вероятностная. Если речь идёт об исследовании «трендов», то вещь, безусловно, полезная. Так там и индексы не особенно нужны.
А вот если мы обрабатываем транзакцию, то «вероятность» не годится. Представьте – сидите вы такой в ресторане с девушкой, проводите картой по терминалу, модель говорит «наверно, ваша карта – вот тут», и... ошибается, нет её там. Здравствуй FULL TABLE SCAN? Или отказ в обслуживании?
Спасибо и за слова, и за вопрос -- он хороший.
Всё-таки «модель» – штука вероятностная.
Модель предсказывает место где лежит нужная запись и она конечно может ошибиться. Но при ошибке происходит не FULL TABLE SCAN, а локальный поиск в некоторой окрестности, и, надо сказать, довольно скромной.
Вот в том же ALEX (https://arxiv.org/pdf/1905.08898.pdf) на рисунке 14 приведено распределение по диапазонам ошибок и оно вызывает твердую уверенность в том, что девушке не придется отрабатывать посудомойкой в ресторане.
Ну, наверно карта тут не самый удачный пример. Потому что если она прошла идентификацию на терминале, значит, в базе она точно есть. А если задача проверить, есть ли такой ключ в базе? Например, проверить владельца карты по "чёрному списку". Без полного сканирования ответить на такой вопрос с полной уверенностью невозможно.
Так вроде и проверяет в примере с картой. Модель и говорит "ключ может быть примерно там", проверит там, проверит окрестность, нет. Значит нет. У банка номер карты кодирует отделение к примеру.
Нет. Тут дело уже не в анатомии СУБД, а в семантике данных. Если вы ищете карту в базе процессинга, то с вероятностью 99.9% она там есть. И если вы что-то нашли, на этом можно остановиться. В таких случаях кеш, например, помогает.
Если вы ищете клиента в «чёрном списке», то в вероятностью 99.99% его там нет, но с полной уверенностью сказать «нет» вы можете, только просмотрев весь набор данных. B-дерево такую уверенность даёт, модель – нет.
Да, получается так и есть, отрицание сложнее задать. Если это вероятностная модель, то скажем верный ответ по черным спискам она будет давать в 99% случаев. Я бы сказал, если это будет работать в 99% случаев и "Результаты очень многообещающие: рост производительности в разы, а размер индекса становится меньше в тысячу раз.", то это точно будут использовать в тех же финансах к примеру. В крайнем случае можно поставить триггер на операции по всем заблокированным картам, ваша модель даже еще и обучится. Т.е. потенциальные потери могут быть меньше чем стоимость владения старым способом. Я думаю, к этому можно относиться как к измерению с погрешностью в физике, только на больших данных.
>Без полного сканирования ответить на такой вопрос с полной уверенностью невозможно.
Возможно, причем полное сканирование для этого не нужно. В их структуре данных ошибаться может только модель в листе, а в промежуточных узлах она точная. Так что спустились вниз, поискали в листе в окрестности -- не нашли, значит действительно нету. И кажется что спускаться до нижнего уровня надо будет только по одному пути.
5 трендов баз данных. Идеи с конференции VLDB’21