AriochАндрей Игоревич1. Найти - это хорошо, но сложно :).

Это легко.

http://www.sql.ru/forum/afsearch.aspx?s=cachedbuffers&submit=?????&bid=20

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

Стало ещё сложнее :).
AriochАндрей Игоревичповреждение данных в обычных условиях кажется мне маловероятным
Да, каждой конкретное повреждение маловероятно.
Но у вас 2 миллиарда байтов только в одоном файле.
Закон больших чисел может вас догнать.

Впрочем, если вы не занимаетесь расчётными функциями, а просто визуализируете посчитанное и данное вам другими - то "случайные изменения в паре десятков чисел ни на что не повлияют"

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

Андрей Игоревичсовременные носители информации, думаю, имеют всякие там суммы и прочие данные
.....крайне дешевы, на грани самоокупаемости. Со всеми вытекающими для запасов прочности - их мало.
а кроме самих дисков - есть ещё межкомпьютерная сеть, есть оперативная память в компьютерах (и у бытовых комьпютеров там никаких ECC близко нет). Хотя если Workstation, то может и быть в принципе.
Ради интереса поинтересуюсь у друга, который как раз работает с программами для АЭС как там всё реализовано на эту тему, но, если честно, первый раз слышу. Так то у меня на компьютере немало расчетных комплексов (аттестованных, с моим кодом не связанных) считается, и о реализации защиты от случайных повреждений данных не слышал, но может и есть что-то, поспрашиваю.
AriochАндрей ИгоревичВ таком случае проще купить больше оперативной памяти и гонять вообще всё в ней

Нет. Скорость винчестеров - чистых, не фрагментированных, подготовленных для потоковой работы - порядка 100 МБ/с
Пусть у вас очень быстрый и очень новый винчестер и там 150 МБ/с
Если же потоковой работы добиться не удастся, то скорость может упасть на порядок.

Скорость оперативной памяти - на 2-3 порядка больше. Лень исктаь цифры, кроме того не знаю какая память в вашей рабочей станции.

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

Обычно всё упрется либо в неумение программы использовать оперативную память для ускорения (привет старым паскалевским типизированным файлам), либо в скорость диска. Если винчестер может передать в секунду в оперативную память например 110 МБ, то больше там "не вырастет", даже есливы купите самую большую и самую быструю память - она просто простаивать будет.

Ну после загона в память массива в 3гб (поля одной кампании) я ни разу не смог уперется в проблему с доступом к данным. По сути для моих текущих задач скорость работы из оперативной была избыточна. Сейчас должны поставить Воркстейшн с 32 ГБ оперативы (64 не дали, жмоты). Так как 10кккк это теоретический максимум значений, а по факту их в десятки раз меньше, то буду весма массив в оперативу загонять, но это решение только для компов с большим объемом оперативы.

AriochАндрей ИгоревичИ стоп в 2 раз. А сколько можно столбцов в БД сделать? 350 можно? Никаких подводных камней не будет? Это, как мне кажется, очень так ускорит заполнение.

Столбцов должно быть столько, сколько есть разнотипных значений.

https://ru.wikipedia.org/wiki/Нормальная_форма
https://habrahabr.ru/post/254773/‎

Не ну это просто правила хорошего тона, но мне-то хорошим быть не обязательно. И если "минимальная логическая избыточность" конфликтует с быстродействием, то почему бы не подзабить на неё :), тем более БД всё равно в таком виде выглядит как костыль.
В мечтах я думал о динамическом создании миллионов таблиц связанных древовидной иерархией, но отпугивает потенциальная сложность и куча подводных камней, которые непременно всплывут.

AriochАндрей ИгоревичВ принципе 50ккк значений

что такое КуКлуксКлан в этом контексте?

КилоКилоКило значений :), я думал это очевидно. Кстати, я тут походу переборщил с этими Кило, в общем 50 (100) миллионов значений имелось в виду.

чччДАндрей Игоревич

Давай чуть-чуть поболтаем.

Можно данные в базу/из базы записывать не по одному элементу, а блоками.
К примеру, есть у тебя 4-х мерный массив, каждая размерность шириной в сто тыщ. Если работать с одной плоскостью (100 000 х 100 000), то понадобится всего 10 млн ячеек памяти. Нормально. Если по твоим алгоритмам ты долго работаешь именно в одной плоскости, то работай с памятью, а как перескочишь на другую - сбрасывай этот блок в базу, доставай оттуда новый и работай с ним. Можно сразу несколько блоков хранить в памяти (например, последние из используемые, или самые часто используемые, или как тебе подсказывает твоя логика обработки данных).

Если честно, то именно так я хотел сделать, но при помощи типизированных файлов, а не БД. Есть ли какие-либо преимущества у БД для подобного вида операций? Тем более что у типизированного файла проще блоки реализовать.

чччД Как это делать.

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

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


Хз что такое класс-"Менеджер" (не, ну я узнал, что в Москве есть такое ООО), но суть я, наверно, понял. У данного способа есть недостаток. Если мне надо пройтись по всему массиву данных (весьма популярный "запрос"), как бы "вдоль" массива (вдоль - по времени) - то придётся поочерёдно загружать - выгружать всё БД для каждого запроса, либо дробить БД на более мелкие элементы.
Хотя я ещё и не проверял (и возможно жестоко заблуждаюсь), но мне кажется, что запрос с диска и так устроит меня по времени отклика. Пока меня больше не устраивает время заполнения базы. Но завтра попробую много столбцов.

Ну и как уже писал, мне больше вариант с типизированными файлами нравится для работы с "Блоками", тем более приложение на делфи 2ГБ типизированный файл с ССД загружает за несколько десятков секунд, сомневаюсь что БД так умеет.

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