MySQL как лучше хранить матрицу

мда... тебе явно рано судить о том, кто где «балаболка» и кто что осилил. В общем спасибо за беседу. На будущее советую в технических тредах использовать техническую аргументацию, а не язык принятый в классе/группе/фирме.

Ах да, на твои детсадоские недоинтерпрайз-задачки, аля у нас удаляется/добавляется хренпойти, а нам там ещё хренпоймичто надо дела и т.п. я клал - мне не интересен этот детсад.

У меня есть определённого сайзофа данные - у меня нет фрагментации. Я могу даже выкинуть ФС. И всё - мне больше ничего не нужно.

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

Когда я храню строки - я храню миллионы строкаблоков в каком-нибудь хафмане. Мне не нужны твоих фекалоподелки.

Я пилю то, что нужно мне, я говорю том, что нужно мне. Я делаю то, что реально полезно мне сейчас. Меня не интересуют ваши детсадовские аргумента, аля «а потом прийдётся переписывать, а кастыли писать долго» и т.п. Я что хочу -то и пишу, а на ваш детсад я клал.

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

Техническая аргументация:

Есть конкретная задача - мой код решает её на 100%. Тебе этого мало? Твои детсадовские предположения, а если «ТСу надо будет удалять, добавлять и т.п.» мне не интересны. Если ему понадобится удалять - он так и сформулирует задачу.

Ещё раз. Мои решения решают ТОЛЬКО конкретно поставленную задачу, а аргументы основанные на «если бы да кобы» меня не интересуют. Надеюсь, я понятно объяснил?

ТС написал только про операции доступа, а твоё уже предоставляет n костылей и не явлется расширяемым by design. Такое решение можно предлагать только дописав его огранниченнойть.

Плюс ты как обычно готов только теоретизировать, а не написать «3 строчки».

Реально? Ну вот когда он напишет о чём-то кроме операции доступа, тогда твоё балабольство будет иметь смысл.

Являетяс абсалютно маштабируемым, причем его масштабируемость привышает на порядки твои лучшие БД. Что там ещё дописывать? Просвяти меня.

Я написал уже 3 строчки, которые делают то, что нужно ТС'у. А продолжать балаболить ты можешь и дальше.

сам напишешь ограничения данного решения?

Какие у него есть ограничения? Я не могу придумать, авось ты сможешь?

нет, ты уж хорошо подумай, и придумай все что есть. Причем хорошо бы разделить твою «proof-of-concept» «реализацию» и реальный код.

Моё решение абсалютно неуязвимо, абсалютно надёжно, абсалютно производительно( дальше только пилить ФС). Что тебе в нём не нравится?

а). зависимость от fs, ограничение на размер из-за fs, ограничение на размер данных из-за разрядности,

б). отсуствие полноценного API, отсутсвие проверок в коде, при их появлении реализация сильно усложнится.

в). отсутсвие уточнения того, какой итоговой интерфейс (язык рантайм) нужен автору.

г). в случае если требуется более адекватное управление используемой памятью придётся переусложнять задачу.

Данное решение является адекватным если:

а). данные только добавляются и достается полная матрица (размер матриц константа);

б). пользователь будет использовать С; (ну или использовать аналог в другом языке)

в). библиотека не будет расширяться.

Т.е. это является преждевременной отпимизацией (это под вопросом кстати) и урезанием функционала так может сделать или кодер или программист полностью знакомый с задачей (не с ТЗ а с задачей).

В большей части случаев гораздо логичнее и проще использовать готовое решение: например sqlite хранить матрицы в таблице {Id::Int,data::Date,matrix::blob}, где в blob хранится сериализованное представление целевого языка ну или просто C-массив float.

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

а). зависимость от fs, ограничение на размер из-за fs, ограничение на размер данных из-за разрядности,

Это проблемы ФС, а не мои - я не фс. Ты юзаешь 32битный х86 - я клал на тебя.

б). отсуствие полноценного API, отсутсвие проверок в коде, при их появлении реализация сильно усложнится.

Там есть ВСЕ проверки. Там есть апи - апдейт апдейтит массив в памяти, который ты можешь юзать после апдейта.

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

г). в случае если требуется более адекватное управление используемой памятью придётся переусложнять задачу.

Это идеальное распределение памяти - оверхед стремится к нулю, такого ты не получишь ни в какой БД.

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

а). данные только добавляются и достается полная матрица (размер матриц константа);

И обновляются(замени на врайт), и удаляются(запиши нули) и обновляются(напиши merge, но как тебе надо обвновлять - это не моя забота)

Их размер всегда константен, а если не константен - с твоим кодом что-то не так.

б). пользователь будет использовать С; (ну или использовать аналог в другом языке)

Либо си, либо 20-30% перфоманса - выбирай. Аналог в сменяемым файлоапи написать хоть на брайнфаке можно.

в). библиотека не будет расширяться.

Что тут расшерять?

Т.е. это является преждевременной отпимизацией (это под вопросом кстати) и урезанием функционала так может сделать или кодер или программист полностью знакомый с задачей (не с ТЗ а с задачей).

Это твоя вера в мистические догматы, не более. Какая оптимизация? Я написал это за 15секунд - ты даже за 5минут такое не напишешь на своём бдапи.

В большей части случаев гораздо логичнее и проще использовать готовое решение: например sqlite хранить матрицы в таблице {Id::Int,data::Date,matrix::blob}, где в blob хранится сериализованное представление целевого языка ну или просто C-массив float.

И получить 3 проблемы:

Дольше пилить

В 3раза тормазнее

Тащит за собой зависимость и прочие какахи, читать какие-то мануалы к скулайту и прочей ереси - тратить свою жизнь на бесполезность.

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

Ты ты хочешь сказать, что писать ИДЕАЛЬНОЕ решение за 15секунд плохо, а писать его после того, как ты слил полчаса на написание аналога на БДапи?

Не, не, увольте - это только в твоих фантазиях.

Решение конкретных задач - удел горе-теоретиков. В реальном мире спецификации всегда неполны и меняются много раз во время выполнения задачи. По-этому решение, которое не учитывает возможности расширения и модификации - на практике бесполезно и имеет ценность лишь для написания убогого диссера.

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

С кешированием оно будет быстрее, чем у этого упоротого.

И обновляются(замени на врайт), и удаляются(запиши нули) и обновляются(напиши merge, но как тебе надо обвновлять - это не моя забота)

А что произойдет, если несколько клиентов одновременно попытаются прочесть/обновить данные?

И получить 3 проблемы:
Дольше пилить
В 3раза тормазнее
Тащит за собой зависимость и прочие какахи, читать какие-то мануалы к скулайту и прочей ереси - тратить свою жизнь на бесполезность.

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

Реально? В твоём детсадовском мире заедушной жабоинтерпрайзе? А ну да.

Какие такие спецификации, какое выполнение задачи - ты что несёшь. Максимум, что тут может поменятся - это НИЧЕГО, что не учитывают мои 3 строчки.

Чего расширения? Чего модификации? Я жду твоей «расширяемой и модифицируемой какаких» - удиви меня, дай мне поржать.

А тут нет кэширования? Запомнил, лалочка, которая не осилили ничего - быстрее моей 3-х строк ты не запилишь НИЧЕГО - это аксиома для таких анскильных сущностей, мышление которых примитивно настолько, что даже своих заедушных каках они ничего не видели.

Каких клиентов? Ты что несёшь? Очередная лалка с мышлением на уровне релябд, жабалибы и 2-го курса недовуза.

Нет тут никаких клиентов, нет тут никакого «одновременного пытания» и прочего - запомни это.

И да, ничего не произойдёт.

Реально? А что у меня не работате - укажи, я поржу.

Если ты вылез из мира заедушного недоинтерпрайза, осилил жабу на уровне 2-го курса, при этом нихрена не понимаешь в работе того, что находится под твоей жвм(да и как работает жвм тыт оже не понимаешь), то твой удел болтать с такими же анскильными соседями по парте/цеху и т.п. Вот там твои аргументы будут иметь смысл.

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

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

Максимум, что тут может поменятся - это НИЧЕГО, что не учитывают мои 3 строчки.

Да тебе уже кучу всего написали, что тут может поменяться. К чтению добавятся операции обновления/удаления, потребуется конкурентный доступ, потребуется хранение какой-то дополнительной информации и сложной выборки таблиц по ней. И во всех этих случаях твое решение не то что just does not work, его просто придется выкинуть.

Хотя вообще у горе-теоретиков всегда так - при встрече с суровой практикой их решение банально выкидывается. А потом пишется новое, в соответствии с требованиями реального мира, а не упоротых ненужных теорий. Ты математик, видимо, скажи честно? Дрочишь на всякие диффуры с алгебрами, небось? Так вот, открою тебе истину - в реальной жизни оно все неприменимо. ИРЛ никогда нету конкретной формулировки, задача всегда является нечеткой. По-этому неуниверсальное «математическое» решение никому нахуй не нужно.

А тут нет кэширования?

В твоих трех строчках нету.

Запомнил, лалочка, которая не осилили ничего - быстрее моей 3-х строк ты не запилишь НИЧЕГО

Я же тебе уже сказал - вариант с кешированием будет обгонять твое трехстрочное говно на _порядки_. Т.к. читать таблицу из файла - это долго, очень долго. А получить уже загруженную в память таблицу из кеша - быстро.

Ю Нет тут никаких клиентов

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

И да, ничего не произойдёт.

То есть не работает. А зачем нужна неработающая программа?

Реально? А что у меня не работате - укажи, я поржу.

Например, удаление/обновление записей у тебя не работает. Нету у тебя в указанных трех строчках этих ф-й.

Да тебе уже кучу всего написали, что тут может поменяться. К чтению добавятся операции обновления/удаления, потребуется конкурентный доступ, потребуется хранение какой-то дополнительной информации и сложной выборки таблиц по ней. И во всех этих случаях твое решение не то что just does not work, его просто придется выкинуть.

Какие же вы глупые, я просто поражаюсь - понадобится - я напишу ещё 2строчки. Обновление/удаление оно уже умеет.

Какой, нахрен, конкуретный доступ? Что ты несёшь. Ты вообще понимаешь как что-то работает. Эта байда НИЧЕМ НЕ ОГРАНИЧЕННА, на ведре она способна выдавать десятки миллионов апдейтов в секунду - она ограничена лишь шустростью твоей оперативы. Никакой конкуретный доступ тут не упал и нужен он только в твоих мечтах.

Никакие выборки не нужны - только анскильным сущностям. Я напишу САМ обработчик для моей карты, а выборка - осиль хешмассив.

Хотя вообще у горе-теоретиков всегда так - при встрече с суровой практикой их решение банально выкидывается. А потом пишется новое, в соответствии с требованиями реального мира, а не упоротых ненужных теорий. Ты математик, видимо, скажи честно? Дрочишь на всякие диффуры с алгебрами, небось? Так вот, открою тебе истину - в реальной жизни оно все неприменимо. ИРЛ никогда нету конкретной формулировки, задача всегда является нечеткой. По-этому неуниверсальное «математическое» решение никому нахуй не нужно.

АХаха, лалка, да я клал на математику, клал на дифуры и считаю их ненужно избыточной байдой - глянь соседний тред.

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

И да, твои решения работают в деревенском гореинтерпрайзе, а там, где нужен порфоманс - работают мои решения.

В твоих трех строчках нету.

man файловый кеш.

Я же тебе уже сказал - вариант с кешированием будет обгонять твое трехстрочное говно на _порядки_. Т.к. читать таблицу из файла - это долго, очень долго. А получить уже загруженную в память таблицу из кеша - быстро.

Давай, давай - я жду разоблачений. Пили, даже на 20% пусть быстрее будет - я тебе памятник поставлю.

Клиент чего?

То есть не работает. А зачем нужна неработающая программа?

Что не работает? Всё работает.

Обновление/удаление оно уже умеет.

Не умеет. Не вижу в твоих трех строках соответствующих ф-й.

Какие же вы глупые, я просто поражаюсь - понадобится - я напишу ещё 2строчки.

Обычный подход горе-теоретика, да. Пишем код, потом выбрасываем его, потом пишем код заново.И так до бесконечности с затратой кучи лишних усилий.

Какой, нахрен, конкуретный доступ?

Обычный.

Эта байда НИЧЕМ НЕ ОГРАНИЧЕННА

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

Я напишу САМ обработчик для моей карты

Молодец. Пока ты будешь писать половину реализации бд, я напишу однострочный SQL запрос и пойду отдыхать.

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

Да нет, это как раз у тебя идеальная конкретная модель (как диффуры), которая в реальности банально _не работает_. Все-таки ты математик. Ну по образу мышления по крайней мере.

Ю а там, где нужен порфоманс - работают мои решения.

Именно по-этому твое решение проигрывает в миллионы раз?

man файловый кеш.

Дебил, файловый кеш-то тут при чем? Ты имел ввиду кеширование жесткого диска, видимо? В любом случае ты еще раз показал, что не более чем горе-теоретик. ИРЛ программа не запускается в сферическом вакууме - есть другие программы, которые могут работать с другими файлами, по-этому нет вообще смысла полагаться на системный файловый кеш, т.к. он непредсказуем и тобой не контролируется. Но даже в твоем идеально-теоретическом случае встроенный кеш будет работать на порядки медленнее, чем обычное if (array) return *array

Клиент чего?

Твоего хранилища данных.

Что не работает?

Программа твоя не работает. Ты же сказал, что она ничего не делает. А если программа ничего не делает - это нерабочая программа. Если, конечно, ничегонеделание не является задачей этой программы. Но мне неясно тогда зачем такая программа вообще нужна.

Какой кеш диска. А ну ясно, очередной маздайский неосилятор.

Ты либо кури матчасть, либо не неси фигню.

Не умеет. Не вижу в твоих трех строках соответствующих ф-й.

uint64_t update(uint64_t i) {
  return (lseek(global_fd, (i * MY_MAP_SIZEOF), SEEK_SET) == (i * MY_MAP_SIZEOF)) && (write(global_fd, global_my_map, MY_MAP_SIZEOF) == MY_MAP_SIZEOF);
}

Вот тебе обновление, если ты настолько анскилен, что не можешь поменять 4символа - удачи.

Обычный подход горе-теоретика, да. Пишем код, потом выбрасываем его, потом пишем код заново.И так до бесконечности с затратой кучи лишних усилий.

Нука, выкати мне такой код: Прочитать карту, инкрементировать кажду координату на 1 и обновить.

Обычный.

Пробалаболился.

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

Как он может прочесть, когда другой пишет - есть там а) одна нить, б) блокирующие rw. Удиви меня, балабол.

Молодец. Пока ты будешь писать половину реализации бд, я напишу однострочный SQL запрос и пойду отдыхать.

Напиши мне то, о чем я написал выше - я погляжу твой однострочник.

Да нет, это как раз у тебя идеальная конкретная модель (как диффуры), которая в реальности банально _не работает_. Все-таки ты математик. Ну по образу мышления по крайней мере.

Она работает, просто она избыточка.

Именно по-этому твое решение проигрывает в миллионы раз?

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

Твоего хранилища данных.

У меня нет никаких храниилишь, клиентов и прочего.

Программа твоя не работает. Ты же сказал, что она ничего не делает. А если программа ничего не делает - это нерабочая программа. Если, конечно, ничегонеделание не является задачей этой программы. Но мне неясно тогда зачем такая программа вообще нужна.

Очередная балаболка - да, ничего, кроме того, что я вложил в этот код не произойдёт.

Я матчасть получше тебя знаю, как выяснилось. Иди читай, что такой файловый кеш, бедняша.

Вот тебе обновление, если ты настолько анскилен, что не можешь поменять 4символа - удачи.

А как теперь сделать, чтобы можно было и читать и изменять? И еще ты про удаление забыл.

Пробалаболился.

где?

Как он может прочесть, когда другой пишет - есть там а) одна нить

Кто сказал, что там одна нить?

б) блокирующие rw.

Замечательно. Я еще раз задам вопрос - что будет, если один клиент попытается прочесть, когда второй пишет?

Напиши мне то, о чем я написал выше - я погляжу твой однострочник.

Ты сначала осиль обновление и удаление. И конкурентный доступ. Потом уже перейдем к индексации и другим интересным вещам.

она избыточка.

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

Чтение, икнремент каждого значения в карте и запись её обратно - я жду от тебя однострочник на sql.

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

У меня нет никаких храниилишь, клиентов и прочего.

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

Очередная балаболка - да, ничего, кроме того, что я вложил в этот код не произойдёт.

Ну что произойдет-то? Если ничего - то программа какая-то бесполезная, ничего не делает. То есть что-то произойти должно же? Что? Неужели, этот столь сложный вопрос? Или ты сам не знаешь, как твоя программа работает?

Нука, удиви меня.

[id], [matrix_id], [X], [Y], [value]

После этого ответа тред можно не читать.

• Отсутствие зависимости от SQlite не нужно
• база дает возможность произвольной выборки данных, если надо, можно будет построить индексы по полям для скорости, которую без БД достигнуть будет крайне сложно (велосипедить реализацию индексов)
• В базе можно хранить сколько угодно много данных и все равно выборка будет относительно быстрой.
• Для матриц есть специальные библиотеки и даже специальные БД для их обработки (на ум приходит ансис, но из свободных тоже что-то должно быть).

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

в решении суперхакира не нужны индексы - смещение элемента банально вычисляется

В базе можно хранить сколько угодно много данных и все равно выборка будет относительно быстрой

"[id], [matrix_id], [X], [Y], [value]" будет намного медленнее чем прямой доступ, вангую, что раз в 20-ть, но это конечно без учета I/O, но во многих случаях кэш его нивелирует

в решении суперхакира не нужны индексы

Но и нормальных выборок с его решением не сделаешь.

Но и нормальных выборок с его решением не сделаешь

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

Но код его превратится в неподдерживаемое говно еще задолго до того, как мы дойдем до нормальных выборок.

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

Нормальный человек запилит нужный ему индекс и будет спать спокойно с 20кратным перфомансом, а ты со своим говном будешь думать «а как мне масштабировать мой фуфле у меня уже на 1к запросов попец».

И да, я не вижу твоей код.

весь тред не читал, но вам, вероятно, нужен netcdf

5000*720*720 это около 2,4 Гб :)

man mmap

сколько ругаться можно? все зависит от задачи. нужна скорость и монопольный доступ - ясен пень C порвет все что угодно. пофиг на скорость или условия другие - юзайте SQL. преждевременная оптимизация корень всех бед) например Торвальдс в Git заюзал свой формат хранения, а не использовал SQL.

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

#define MY_MAP_SIZEOF 720*720*sizeof(float)
float global_my_map[720*720];
int global_fd, global_shit_fd;

uint64_t offset_read(uint64_t i) {
  return (lseek(global_fd, (i * MY_MAP_SIZEOF), SEEK_SET) == (i * MY_MAP_SIZEOF)) && (read(global_fd, global_my_map, MY_MAP_SIZEOF) == MY_MAP_SIZEOF);
}

uint64_t offset_write(uint64_t i) {
  return (lseek(global_fd, (i * MY_MAP_SIZEOF), SEEK_SET) == (i * MY_MAP_SIZEOF)) && (write(global_fd, global_my_map, MY_MAP_SIZEOF) == MY_MAP_SIZEOF);
}
enum {
  FILE_IS_NOT_REMOVE = 0,
  FILE_IS_REMOVE = 1, 
};

uint8_t shit_index[1 << 13];

uint64_t shit_remove(uint64_t i) {
  if(i & (-1ul << 13)) exit(1);
  shit_index[i] = FILE_IS_REMOVE;
}

uint64_t shit_read(uint64_t i) {
  if(i & (-1ul << 13)) exit(1);  
  if(shit_index[i]) return 123;  
  return offset_read(i);  
}

uint64_t shit_write(uint64_t i) {
  if(i & (-1ul << 13)) exit(1);  
  return (offset_write(i) && !(shit_index[i] = FILE_IS_NOT_REMOVE));
}

int main(void) {
   global_fd = open("test.mapdump", O_RDWR);
   global_shit_fd = open("test.shit_index", O_RDWR);
   read(global_shit_fd, shit_index, sizeof(shit_index));
     
   fprintf(stderr, "%lu\n", shit_read(10));
   fprintf(stderr, "%lu\n", shit_remove(10)); 
   lseek(global_shit_fd, 0, SEEK_SET);
   write(global_shit_fd, shit_index, sizeof(shit_index));
}

Вот последняя портянка, ибо её снесли.

в решении суперхакира не нужны индексы - смещение элемента банально вычисляется

А при чем тут смещение элемента ? Это троллинг, или ты правда не понимаешь в чем смысл выборки по значениям ?

"[id], [matrix_id], [X], [Y], [value]" будет намного медленнее чем прямой доступ, вангую, что раз в 20-ть, но это конечно без учета I/O

Ну это только если mmap и конечно только на 64 битной системе (на 32 битной только 4 гига) и уж конечно, если точно знаешь адрес ячейки, ну, то есть, без выборок, как в предыдущем пункте.

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

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

Ну это только если mmap и конечно только на 64 битной системе

нет, это оптимистичная оценка оверхеда поверх банальной работы с файлом, она основана на реальных тестах sqlite, который я сам часто использую, и да - это уже без synch и с prepared statements

А при чем тут смещение элемента ? Это троллинг, или ты правда не понимаешь в чем смысл выборки по значениям ?

Выборки по значением чего? Каждого флоата из 3-х миллиардов? Удивил.

А если тебе нужно добавить какую-то индексацию, как я уже говорил - осиль хешмассив.