Индексация больших объемов данных

ЩИТО?

найдите ка ВСЕ корни бисекцией для непрерывной немонотонной функции, у которой скажем этих корней на исходном отрезке три. Я подожду.

нет, ты неправильно понял, это википедия твоя так считает, а я считаю это бредом сивой кобылы.

читай внимательно то что тебе пишут, если что-то непонятно - перечитай ещё раз.

как ты считаешь, сколько корней может быть на отрезке у монотонной непрерывной функции?

найдите ка ВСЕ корни бисекцией для непрерывной немонотонной функции, у которой скажем этих корней на исходном отрезке три. Я подожду.

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

Вы так много написали, что я прям теряюсь что именно читать. Не могли бы Вы повторить для лменя убогого, чем же все таки отличается метод половинного деления от бинарного поиcка? Без всякого изображения сарказма, просто можете ответить на вопрос?

sqlite... но раз ты настаиваешь: leveldb. использую у себя для похожего, и теперь считаю, что надо было брать sqlite

У монтонной один. Но для бисекции монтонность не требуется, требуется непрерывность. У непрерывной НЕ монтонной ф-ии при условии что на границах отрезка значения имеют разные знаки, корней на отрезке может быть любое положительное нечетное число. Пример \cos(w t) при t\in [0,\pi].

Метод бисекции очевидно позволяет найти ОДИН из корней, но иногда приходится искать ВСЕ корни.

И мне таки не нравится Ваш тон.

теперь считаю, что надо было брать sqlite

В sqlite хранить терабайт данных? Смело

кто тебя заставляет засовывать блобы в sqlite? Индекс в базу. Блобы в файлах. Индекс будет на пару порядков меньше размером. У меня - сотня гигов на 20 терабайтное блобьё

сотня гигов

Возможно сейчас что-то изменилось но пару-тройку лет назад sqlite на бд в несколько гигабайт еле ворочался

да, я не проверял sqlite на таком объеме, интересно конечно. Может руки дойдет.

По сути, меня leveldb не устраивает некоторым примитивизмом и отсутствием административных инструментов для анализа существующей базы.

в инертности мышления меня обвиняет человек, который строит индекс на сортированном массиве? смело и оригинально

А что Вы можете еще предложить?

Можете предложить решение со скоростью доступа O(1)?

могу предложить то, что люди используют на реальном, а не теоретическом железе

могу и O(log log N)

могу и O(1)

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

И мне таки не нравится Ваш тон.

Не несите чепухи и с Вами будут разговаривать в нормальном тоне.

Я уже Вам все разжевал, но если Вы не умеете читать, то я могу сколько угодно писать - до Вас не дойдет смысл написанного. Именно поэтому я раньше уже говорил, что я бессилен Вам что-либо объяснить.

adios

Вы к сожалению ничего вразумительного, кроме «ЩИТО», тут не написали.

И я с сожалением вынужден констатировать, что Вы батенька, Кудреватых Александр, хамоватое трепло. К тому же то ли читать не умеющее, то ли некомптентное в обсуждаемом вопросе.

Фу быть таким...

ага, ну то есть такого фундаментального ничего нет, что-ж я так и думал, спасибо

то что на курсах в «универах» я более или менее представляю и так, там все достаточно просто

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

Наск я понимаю, тут самое сложное определится с типовыми видами запросов.

ну это то как раз просто, пример запроса: выдать все зарегистрированные фотоны в такой-то области )

там надо эффективным образом их уметь выбирать/хранить (под достаточно толстой нагрузкой), и это, в принципе, понятно как делать, но хотелось бы, что-ли, некоторое введение в принципы построения подобных СУБД эффективным образом

«Эффективным образом» по какому параметру?

Если выборка только по области, область м.б. произвольных размеров, и область наск я понимаю 2D (небо?), то посмотри в сторону Z-curve обхода. Он конечно и в сторону больших размерностей обощается, и это как бы квинтессенция модной тейловой архитектуры;-)

PS Видать во вт. или ср. буду делать семинар по сейсмич. миграции, приходи.

«Эффективным образом» по какому параметру?

по пространственным координатам, там будет еще мета-информация, но это уже потом и это более понятно как делать

Если выборка только по области, область м.б. произвольных размеров, и область наск я понимаю 2D (небо?),

да, конечно, небо, там будет 2D + 3D, так что смотрю по максимуму

то посмотри в сторону Z-curve обхода.

уже, двумя глазами, пока только не совсем понятно как его правильно в индексе на диске реализовывать (то есть куда ехать понятно, но хотелось бы понять куда соломки подложить :))

Он конечно и в сторону больших размерностей обощается, и это как бы квинтессенция модной тейловой архитектуры;-)

ага :)

PS Видать во вт. или ср. буду делать семинар по сейсмич. миграции, приходи.

с удовольствием, спасибо за приглашение

Ну давай, до/после семинара и поговорим о z-курвах, Вадим как раз в этом не одну собаку съел. Или даже сделай у нас доклад, если хошь;-)

Ну давай, до/после семинара и поговорим о z-курвах, Вадим как раз в этом не одну собаку съел.

с удовольствием, спасибо :-)

Или даже сделай у нас доклад, если хошь;-)

только после того как запилю работающее решение

но КО считает, что ты пользовался бинарным поиском, а не методом половинного деления.

а в лоб больнее, чем по лбу?

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

ок, что такое «дихотомия»?

нет, ты неправильно понял, это википедия твоя так считает, а я считаю это бредом сивой кобылы. читай внимательно то что тебе пишут, если что-то непонятно - перечитай ещё раз.

ты упоролся. А википедики в данном конкретном случае всё правильно написали.