Всем доброго времени суток!
Я до этого сталкивался только с небольшими по объёму проектами на MySQL и Firebird.
Но сейчас появилась необходимость сделать БД для хранения архива большого объёма данных, но требуется быстрый поиск по архиву (не более 15 сек на запрос).
Поэтому хотелось бы услышать советы от людей которые уже прошли по таким граблям 
Интересует какую СУБД лучше использовать для решения этой задачи, как правильно организовать структуру таблиц и прочие нюансы, чтоб не пришлось потом всё переделывать заново.

Что собственно нужно:
- хранить данные от 3400 источников поступающие ежесекундно, в формате [номер источника | дата записи | текущее показание] 
- возможность выборки данных по любому источнику (максимум 2-3 дня) ... в дальнейшем на основе выборок будут строится графики.

Выборки будут проводиться редко, 5-10 выборок по 3-7 источникам в день, основная нагрузка запись в БД.
Так как проект не коммерческий то в поле зрения попадают только свободные СУБД, как писал выше есть небольшой опыт работы с MySQL и Firebird, но рассмотрю и другие варианты.
Понимаю что объём данных будет просто огромный  ... предполагаю что в базу буду писать не все данные подряд, а только изменения или даже придётся усреднять немного ... но легче всё равно не будет 
Мощного железа ждать тоже не придётся.

Жду ваших советов 
 

Так что за выборки-то? От этого (и "15 секунд на запрос") и придётся плясать в выборе методики хранения (и формата, и индэксов, если потребуются).
И потом ужэ думать -- возможно такое записать, или невозможно.

Вообще 3400 источников, ежесекундно - по объему походит на технологии Big data. Почитайте тут

Скорее всего Вам придется иметь дело с NoSQL СУБД типа Redis, MangoDB. Также можно смотреть в сторону СУБД Oracle Database и MS SQL Server.

Этот ответ добавлен с нового Винграда - http://vingrad.com

выборка вида: получить все данные с такого-то числа по такое-то число источника номер такой-то ...

просто массив данных показание + дата + время

3400 источников, ежэсекундно, по 20 допустим байт на источник -- это аж цэлых 70 килобайт в секунду. Пигдатей некуда, чо. Ну да, за год -- получается два тэрабайта. Но два тэрабайта -- это тожэ нормальный домашний HDD.



У Вас уровень хабра, честное слово.

Добавлено через 8 минут и 50 секунд


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

Запись в каждый файл осуществлять большыми порцыями (килобайт хотя бы по 256). Да, придётся долго ждать (по часу), пока записи не попадут в окончательный файл. И записи будут теряться при пропадании питания -- хотя это, как раз, вопрос решаемый, за счёт сплошного журнала, в который записывается до записи в основные файлы. Учитывая достаточно детский объём записываемого (70 kB/s) -- можно себе позволить.

Место в файле резервировать ещё бОльшыми порцыями. Мегобайт по 50. Чтобы просто оно последовательно было, для удобства выборки.

Выборка источника такого-то за такое-то время будет банальной: по времени -- вычисляешь смещение, берёшь и читаешь всё, что записано. Чтение -- линейное, так что скорость будет близка к скорости чтения со шпинделя. Итого год одного источника будет читаться секунды за 3.

Поискать потоковую СУБД именно под твоё применение можно -- я в них не очень, честно говоря, разбираюсь. Но готовая СУБД -- это некоторые накладные расходы, плюс чаще всего расходы на её администрирование, твоё обучение. Надо ли всё это в таком простом случае?

Добавлено через 12 минут и 37 секунд
Да, про резервирование места под файлы --- если не резервировать, то файлы будут записаны на диск вперемешку, что приведёт к сильному падению линейной скорости чтения из одного файла. В общем, до некоторой степени это допустимо -- но надо ли?
И про запись большыми блоками по десяткам, а то и сотням килобайт -- запись в параллель в 3400 разных файлов, каждый из которых зарезервировал для себя по несколько десятков мегабайт, приведёт к тысячам перемещений головки в секунду. А оно небыстрое, дажэ в рамках примерно одной области диска. Так что методом в лоб можно просто неуспеть это всё записать, дажэ на мизерной скорости 70 килобайт в секунду. Да и если успеет -- то всё равно остаток скорости диска на чтение сильно поуменьшытся.

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

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

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

Добавлено через 6 минут и 17 секунд

Проект то не коммерческий, поэтому СУБД Oracle Database и MS SQL Server не совсем подходят 

И всё таки мне кажется Big data это не мой случай, сложно всё там 

О, спасибо, tzirechnoy, научили считать объем данных. Да, не big data. Интересно, а big data - это начиная с какого объема?

Этот ответ добавлен с нового Винграда - http://vingrad.com

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

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

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

Этот ответ добавлен с нового Винграда - http://vingrad.com

Опять же если в задаче стоит удаленная БД, то для записи в файл или писать сервис( еще клиент-серверное приложение) или отказаться от этой затеи... Еще многое будет зависеть от ОС и сервера БД и их настройки, как они скидывают кэш БД в БД. Касательно огнептицы если 32-х битная версия, там счетчик транзакций у тебя при такой интенсивности быстро закончится, 2 миллиарда всего. А у тебя 3400*3600 сек*24 ч= 293 760 000 транзакций/день, т.е. через ~6 дней работы. ID записи, если тип integer чуть позже на пару часов закончится. В этом плане работа с файлом удобней. Надо думать про этот момент. Да и резервной копии тоже нужно время (для создания) и место на HDD.

Этот ответ добавлен с нового Винграда - http://vingrad.com

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

Я просто встрял на слове "ароматность". Что это? Кто это выдумал? Зачем?

Да, а что не так с дурабилити в предложэнной мной схеме с двумя журналами?

Спилчекер не всегда друг, но иногода и враг 
Забавно получилось. Полагаю ты понял, что я имел в виду "атомарность"

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

Серьезно? Удивлен. Уверен был, что ты знаком с аббревиатурой ACID