Требуется совет в создании БД

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

Что собственно нужно:
- хранить данные от 3400 источников поступающие ежесекундно, в формате [номер источника | дата записи | текущее показание] 

4517 | 25.07.2015 02:24:15 | 045.815

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

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

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

Ответы (15)
ava
tzirechnoy | 30.07.2015, 11:22 #
Так что за выборки-то? От этого (и "15 секунд на запрос") и придётся плясать в выборе методики хранения (и формата, и индэксов, если потребуются).
И потом ужэ думать -- возможно такое записать, или невозможно.
ava
Game-lot | 30.07.2015, 12:21 (Отредактирован 30.07.2015 12:23) #
Вообще 3400 источников, ежесекундно - по объему походит на технологии Big data. Почитайте тут

Скорее всего Вам придется иметь дело с NoSQL СУБД типа Redis, MongoDB. Также можно смотреть в сторону СУБД Oracle Database и MS SQL Server.
ava
Interruption | 30.07.2015, 12:57 #
Цитата (tzirechnoy @ 30.7.2015,  11:22)
Так что за выборки-то?

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

просто массив данных показание + дата + время
ava
tzirechnoy | 30.07.2015, 15:35 #
Цитата
Вообще 3400 источников, ежесекундно - по объему походит на технологии Big data.


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

Цитата
Вам придется иметь дело с NoSQL СУБД типа Redis, MangoDB.


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

ava
Game-lot | 31.07.2015, 13:43 #
О, спасибо, tzirechnoy, научили считать объем данных. Да, не big data. Интересно, а big data - это начиная с какого объема?
ava
Interruption | 31.07.2015, 09:59 #
Хм, спасибо за идею писать в файл, как то даже в голову не пришло.

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

А вот при записи всех источников в один файл, ведь придётся искать нужную информацию ? Просто прочитать нужный кусок не получится ... или я не прав ?
ava
tzirechnoy | 31.07.2015, 14:19 #
Цитата
Интересно, а big data - это начиная с какого объема?


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

Вот когда у людей четверть тэрабайта важных данных в сутки -- это ужэ, наверное, оно. Особенно если клиенты хотят доступ к результатам, рассчитанным на этих данных on-line.
ava
barmaley4ik | 30.10.2015, 14:22 #
Тоже первая мысль пришла писать все в файл, а потом парсить его для отчетов. Тут нужно тестить. Тест залива в бд и файл инфу за какой-то период. И тест выборки. Тут много зависит от организации клиентского приложения, железа и выбора сервера БД (файла). По клиентскому приложению будет ли поддерживать оно многопоточность. Тоже самое по железу и серверу БД. Да и БД можно сделать несколько ранжировать или по периоду или по клиентам чьи данные заливаются. Все зависит от фантазии и прямых рук)))
ava
barmaley4ik | 30.10.2015, 14:40 #
Опять же если в задаче стоит удаленная БД, то для записи в файл или писать сервис( еще клиент-серверное приложение) или отказаться от этой затеи... Еще многое будет зависеть от ОС и сервера БД и их настройки, как они скидывают кэш БД в БД. Касательно огнептицы если 32-х битная версия, там счетчик транзакций у тебя при такой интенсивности быстро закончится, 2 миллиарда всего. А у тебя 3400*3600 сек*24 ч= 293 760 000 транзакций/день, т.е. через ~6 дней работы. ID записи, если тип integer чуть позже на пару часов закончится. В этом плане работа с файлом удобней. Надо думать про этот момент. Да и резервной копии тоже нужно время (для создания) и место на HDD.
ava
Zloxa | 30.11.2015, 22:50 #
Цитата (tzirechnoy @  30.7.2015,  16:35 findReferencedText)
а писать в файлы самому

Я так понимаю ароматностью, согласованностью, изолированностью можно пренебречь исходя из постановки, но на основании чего возникло ощущение, что и дурабилити можно пренебречь? smile
ava
tzirechnoy | 02.12.2015, 15:54 #
Я просто встрял на слове "ароматность". Что это? Кто это выдумал? Зачем?

Да, а что не так с дурабилити в предложэнной мной схеме с двумя журналами?
ava
Zloxa | 02.12.2015, 21:50 #
Цитата (tzirechnoy @  2.12.2015,  16:54 findReferencedText)
Я просто встрял на слове "ароматность". Что это? Кто это выдумал? Зачем?

Спилчекер не всегда друг, но иногода и враг smile
Забавно получилось. Полагаю ты понял, что я имел в виду "атомарность"
ava
tzirechnoy | 03.12.2015, 20:53 #
Нет, сам не догадался. Ну, тут в общем бог бы с ней, с атомарностью: что записалось -- записалось, что недозаписалось -- как и не было.
ava
Zloxa | 03.12.2015, 21:07 #
Цитата (tzirechnoy @  3.12.2015,  21:53 findReferencedText)
Нет, сам не догадался. 

Серьезно? Удивлен. Уверен был, что ты знаком с аббревиатурой ACID
ava
tzirechnoy | 03.12.2015, 23:16 #
Я почему-то постоянно забываю, как она расшыфровывается. Потому, тем более по русски, совершэнно не идэнтифицыровал.
Зарегистрируйтесь или войдите, чтобы написать.
Фирма дня
Вы также можете добавить свою фирму в каталог IT-фирм, и публиковать статьи, новости, вакансии и другую информацию от имени фирмы.
Подробнее
Участники
advanced
Отправить