похожая тема уже поднималась на Хабре, но для небольших размерностей (2-3) и применительно к дисковой БД PostgreSQL
— там кстати и 8 мерный индекс был и 128-мерный.
Если ваше B-дерево имеет страничную организацию, без разницы где находятся страницы — в памяти или на диске.
Остроумно, кстати. Единственно, при неудачном стечении обстоятельств таких выходов/возвратов может быть очень много.
А вы пытались профилировать работу, смотреть кто занимает процессор?
Допустим у нас двойная ошибка с слове памяти и этой линии нет в кэше, откуда её можно было бы восстановить.
Система не может просто так продолжать работать на оставшихся двух т.к. случись снова ошибка, голосовать будет некому. Надо как можно скорее восстановить кворум. Если отпустить те два компа в работу, возможно, догнать будет непросто и не быстро, всё это время система будет нестабильна.
Засинхронизоваться — как вы себе это представляете?
Пока один продолжает работать, другой из под него страницы выдёргивает?
Кто должен определять какие результаты должны совпасть?
Эффекты воздействия полной дозы связаны с накоплением этого положительного заряда в диэлектриках
А насколько быстро дырки и электроны рекомбинируют, если обесточить схему?
А может даже замкнуть всё накоротко.
Как быстро схема придёт в рабочее состояние?
Кривая Гильберта (пусть N-мерная) получается из N-мерного единичного куба
(с обходом вершин). Я его называю симплексом кривой Гильберта.
Заменяя точки этого куба на такой же куб, получаем куб со стороной 2.
Если еще раз — 4. Там ниже иллюстрация того, как это происходит.
Вообще, NULL-ы — довольно токсичная штука, всё что с ними соприкасается тоже становится NULL-ом. Вот если вы хотите поместить такое значение в индекс, где оно окажется — в начале, конце (может сбоку)?
По вашей ссылке вижу попытку подменить null-ы «неизвестным значением».
Сошлюсь на несколько идеалистическую книжку Дейта и Дарвена «Database Explorations»
(см. «Chapter 27 Is SQL’s Three-Valued Logic Truth Functionally Complete?»,
«Chapter 28 A Critique of Nulls, Three-Valued Logic, and Ambiguity in SQL:
Critiquing Date's Critique») и просто на вики :).
Мысль то симпатичная: пусть конкретное поле — это наличие некоторого слова из словаря, давайте построим полнотекстовый индекс.
Но это эквивалентно построению одиночного индекса на каждое логическое поле,
так даже компактнее полнотекстового, ведь номер слова не присутствует.
А если перекос в обратную сторону — почти все true и лишь иногда false?
Нет смысла индексировать поле, если нет статистического перекоса.
С другой стороны, сегодня перекоса нет, а завтра есть.
В результате многомерный индекс получится и компактнее и быстрее.
Почему вы решили, что этот запрос использует индекс?
Почему нельзя проиндексировать факт «field is null»?
Какой физический смысл в индексации NULL-ов вместе с данными?
Капуста будет дальше.
Если ваше B-дерево имеет страничную организацию, без разницы где находятся страницы — в памяти или на диске.
А вы пытались профилировать работу, смотреть кто занимает процессор?
И попробуйте в следующий раз обойтись без хамства.
Система не может просто так продолжать работать на оставшихся двух т.к. случись снова ошибка, голосовать будет некому. Надо как можно скорее восстановить кворум. Если отпустить те два компа в работу, возможно, догнать будет непросто и не быстро, всё это время система будет нестабильна.
Засинхронизоваться — как вы себе это представляете?
Пока один продолжает работать, другой из под него страницы выдёргивает?
Кто должен определять какие результаты должны совпасть?
А может даже замкнуть всё накоротко.
Как быстро схема придёт в рабочее состояние?
(с обходом вершин). Я его называю симплексом кривой Гильберта.
Заменяя точки этого куба на такой же куб, получаем куб со стороной 2.
Если еще раз — 4. Там ниже иллюстрация того, как это происходит.
По вашей ссылке вижу попытку подменить null-ы «неизвестным значением».
Сошлюсь на несколько идеалистическую книжку Дейта и Дарвена «Database Explorations»
(см. «Chapter 27 Is SQL’s Three-Valued Logic Truth Functionally Complete?»,
«Chapter 28 A Critique of Nulls, Three-Valued Logic, and Ambiguity in SQL:
Critiquing Date's Critique») и просто на вики :).
Но это эквивалентно построению одиночного индекса на каждое логическое поле,
так даже компактнее полнотекстового, ведь номер слова не присутствует.
А если перекос в обратную сторону — почти все true и лишь иногда false?
Нет смысла индексировать поле, если нет статистического перекоса.
С другой стороны, сегодня перекоса нет, а завтра есть.
В результате многомерный индекс получится и компактнее и быстрее.
А чем это будет отличаться от варианта — «давайте просто проиндексируем все логические поля»?
Почему нельзя проиндексировать факт «field is null»?
Какой физический смысл в индексации NULL-ов вместе с данными?