Доброго времени суток! Интересует вопрос по базе данных очень большого размера. База должна будет состоять из двух основных параметров. - вопрос №2606722

1 — начнем с конца — в вашем описании «0002045» откровенная строка а не число. если вам важны ведущие 0 тогда это строка… но допустим что с точностью 6+6 знаков, то есть не менее 12, можно использовать число с плавающей точкой для сокращения объема памяти — 12 символов строки это 12 байтов обычной кодировки, но базы данных сейчас вообще то все чаще по умолчанию работают с unicode, и в зависимости от реализации это могут быть и все 24 байта, а числа с плавающей точкой бывают 4, 6, и 8 байтов, в зависимости от требований точности. для надежности предположим что 8 уж точно хватит

2 — дата/время — сразу выкинем неделю, она элементарно вычисляется на основе просто даты год-месяц-число. на примере MS SQL Server, размер даты зависит от диапазона дат (от 01/01/1753 до 31/12/9999 «большой», от 01/01/1900 до 06/06/2079 «малый» диапазоны, если не влезает в «большой» — надо изобретать уже свой формат) и точности времени (точность до трехсотых долей секунды или до числа минут с момента полуночи) — это 4+4 байта или 2+2 соответсвенно… то есть 8 байтов хватит наверняка

3 — 8+8=16 байтов «сырых данных» одной записи * «315 миллионов 360 тысяч штук»… 16Х315'360'000=5'045'760'000 байтов… переведем в двоичные «кило» (:1024) = 4'927'500 потом в двоичные «мега» (:1024) = ~4'812,01 и наконец «гига» (:1024) = ~4,699 — около 5 Гб

пустяки для современных хардов ;)

хотя в действительности реальный файл базы будет содержать кучу служебной информации, пусть это будет в 2 раза больше (с запасом) = 10 Гб, с таким обьемом справится даже самая популярная «легковесная» субд SQLite — ru.wikipedia.org/wiki/SQLite см «ограничения»

но это только данные, для быстрого доступа потребуются индексы, а это будет НЕ меньше по объему = порядка 20 Гб дискового пространства. это очень на вскидку. на самом деле возможно есть варианты оптимизации, все зависит от конечной цели

о скоростях — суперкомпьютер тут точно не нужен, хотя и слабенький/старый уже будет тяжело ворочать — нужен средний «офисный» современный компьютер, даже не игровой

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

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

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

ps

кроме того — судя по простой структуре данных, возможно самые быстрые варианты будут как раз не в использовании универсальной СУБД, а в разработке специальной программы. учитывая что «сырые данные» могут быть загружены полностью в оперативку (к примеру ставим 16 Гиг оперативки) то можно отбросить огромное количество лишних возможностей универсальной субд, и запрограммировать в чистом виде то что нам надо. выиграть по скорости против СУБД, на простых задачах конечно, можно и в 100 раз, если все данные доступны одним куском в памяти. но продумать такие вариант можно только зная конечную цель обработки