Я понимаю, что индексы имеют такие недостатки, как медленнее INSERT/UPDATE, требования к пространству и т.д. Но в моем случае я сначала обрабатываю и загружаю большую партию данных в Spark SQL, а затем исследую эти данные в целом без дальнейшие изменения. Spark SQL полезен для начальной распределенной обработки и загрузки данных, но отсутствие индексации делает интерактивные исследования медленнее и громоздкими, чем я ожидал.
Мне интересно, почему команда Spark SQL считает, что индексы неважны до такой степени, что они не совпадают с их дорожной картой. Есть ли другой шаблон использования, который может обеспечить преимущества индексации, не прибегая к реализации чего-то эквивалентного независимо?
Ответ 2
В общем, полезность индексов в лучшем случае сомнительна. Вместо этого важнее разделение данных. Это очень разные вещи, и только потому, что ваша база данных по выбору поддерживает индексы, это не значит, что они имеют смысл, учитывая то, что пытается сделать Spark. И это не имеет ничего общего с "в памяти".
Итак, что такое индекс?
В те дни, когда постоянное хранилище было сумасшедшим (вместо, по сути, свободным), системы реляционной базы данных были связаны с минимизацией использования постоянного хранилища. Реляционная модель, по необходимости, разбила запись на несколько частей - нормализовала данные - и сохранила их в разных местах. Чтобы прочитать запись клиента, возможно, вы прочитали таблицу customer, таблицу customerType, извлеките пару записей из таблицы address и т.д. Если у вас есть решение, требующее, чтобы вы прочитали всю таблицу найти то, что вы хотите, это очень дорого, потому что вам нужно сканировать так много таблиц.
Но это не единственный способ сделать что-то. Если вам не нужны столбцы фиксированной ширины, вы можете хранить весь набор данных в одном месте. Вместо того, чтобы выполнять полноэкранное сканирование в связке таблиц, вам нужно сделать это только в одной таблице. И это не так плохо, как вы думаете, особенно если вы можете разбить свои данные.
Спустя 40 лет законы физики изменились. Скоростные скорости чтения/записи на жестком диске и линейные скорости чтения/записи резко расходятся. Вы можете в основном сделать 350 движений головы за секунду на диск. (Немного больше или меньше, но это хорошее среднее число.) С другой стороны, один диск может читать около 100 МБ в секунду. Что это значит?
Сделайте математику и подумайте об этом - это означает , если вы читаете менее 300 Кбайт на движение головки диска, вы дросселируете пропускную способность своего диска.
Seriouusly. Подумайте об этом секунду.
Цель индекса - позволить вам переместить головку вашего диска в нужное место на нужном диске и просто прочитать эту запись - скажем, только запись address, объединенная как часть вашей записи customer. И я говорю, что это бесполезно.
Если бы я составлял индекс, основанный на современной физике, мне нужно было бы получить только 100 КБ целевой части данных (если бы мои данные были выложены большими кусками), но мы говорим о теории здесь все равно). Основываясь на приведенных выше цифрах, больше точности, чем это просто отходы.
Теперь вернитесь к своему стандартизованному дизайну стола. Скажем, что запись customer действительно разделена на 6 строк, хранящихся в 5 таблицах. 6 всего движения головки диска (я предполагаю, что индекс кэшируется в памяти, поэтому нет движения диска). Это означает, что я могу читать 1,8 МБ линейных/де-нормированных записей клиентов и быть таким же эффективным.
А как насчет истории клиентов? Предположим, я хотел не просто посмотреть, как выглядит клиент сегодня - представьте себе, что я хочу полную историю или подмножество истории? Умножьте все выше на 10 или 20, и вы получите изображение.
Что лучше, чем индекс, будет разделение данных - убедитесь, что все записи клиентов попадают в один раздел. Таким образом, с движением одного диска, я могу прочитать всю историю клиента. Движение одной головки диска.
Скажите еще раз, почему вы хотите индексы.
Индексы против ___?
Не поймите меня неправильно - есть ценность в "предварительном приготовлении" ваших поисков. Но законы физики предлагают лучший способ сделать это, чем традиционные индексы. Вместо того, чтобы хранить запись клиента только в одном месте и создавая указатель на нее - индекс - почему бы не сохранить запись в нескольких местах?
Помните, что дисковое пространство по существу бесплатное. Вместо того, чтобы пытаться свести к минимуму объем используемого хранилища - устаревший артефакт реляционной модели - просто используйте свой диск в качестве кеша поиска.
Если вы считаете, что кто-то хочет видеть клиентов, перечисленных как по географии, так и по продажам, сделайте несколько копий ваших записей клиентов таким образом, чтобы оптимизировать эти запросы. Как я уже сказал, используйте диск, подобный вашему в кеше памяти. Вместо того, чтобы создавать свой кеш в памяти, объединяя разрозненные фрагменты постоянных данных, создайте свои постоянные данные, чтобы отразить ваш кеш в памяти, поэтому все, что вам нужно сделать, это прочитать его. На самом деле даже не пытайтесь хранить его в памяти - просто прочитайте его прямо с диска каждый раз, когда вам это нужно.
Если вы думаете, что это звучит сумасшедшим, подумайте об этом - если вы будете кэшировать его в памяти, вы, вероятно, будете кэшировать его дважды. Вероятно, ваш контроллер OS/drive использует основную память в качестве кеша. Не беспокойтесь о кешировании данных, потому что кто-то еще уже!
Но я отвлекаюсь...
Короче говоря, Spark абсолютно поддерживает правильный тип индексации - способность создавать сложные производные данные из необработанных данных, чтобы сделать использование в будущем более эффективным. Он просто не делает этого так, как вы этого хотите.
