Модераторы: LSD

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Требуется совет в создании БД, Большой архив с быстрым доступом 
:(
    Опции темы
Interruption
Дата 29.7.2015, 09:53 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 3
Регистрация: 28.7.2015

Репутация: нет
Всего: нет



Всем доброго времени суток!
Я до этого сталкивался только с небольшими по объёму проектами на 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
 

PM MAIL   Вверх
tzirechnoy
Дата 30.7.2015, 11:22 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1173
Регистрация: 30.1.2009

Репутация: 0
Всего: 16



Так что за выборки-то? От этого (и "15 секунд на запрос") и придётся плясать в выборе методики хранения (и формата, и индэксов, если потребуются).
И потом ужэ думать -- возможно такое записать, или невозможно.
PM MAIL   Вверх
Game-lot
Дата 30.7.2015, 12:21 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 38
Регистрация: 8.11.2007

Репутация: нет
Всего: 2



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

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

Этот ответ добавлен с нового Винграда - http://vingrad.com
PM MAIL   Вверх
Interruption
Дата 30.7.2015, 12:57 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 3
Регистрация: 28.7.2015

Репутация: нет
Всего: нет



Цитата(tzirechnoy @ 30.7.2015,  11:22)
Так что за выборки-то?

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

просто массив данных показание + дата + время
PM MAIL   Вверх
tzirechnoy
Дата 30.7.2015, 15:35 (ссылка) |    (голосов:1) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1173
Регистрация: 30.1.2009

Репутация: 0
Всего: 16



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


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

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


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

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


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

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

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

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

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

Добавлено через 12 минут и 37 секунд
Да, про резервирование места под файлы --- если не резервировать, то файлы будут записаны на диск вперемешку, что приведёт к сильному падению линейной скорости чтения из одного файла. В общем, до некоторой степени это допустимо -- но надо ли?
И про запись большыми блоками по десяткам, а то и сотням килобайт -- запись в параллель в 3400 разных файлов, каждый из которых зарезервировал для себя по несколько десятков мегабайт, приведёт к тысячам перемещений головки в секунду. А оно небыстрое, дажэ в рамках примерно одной области диска. Так что методом в лоб можно просто неуспеть это всё записать, дажэ на мизерной скорости 70 килобайт в секунду. Да и если успеет -- то всё равно остаток скорости диска на чтение сильно поуменьшытся.
PM MAIL   Вверх
Interruption
Дата 31.7.2015, 09:59 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 3
Регистрация: 28.7.2015

Репутация: нет
Всего: нет



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

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

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

Добавлено через 6 минут и 17 секунд
Цитата(Game-lot @ 30.7.2015,  12:21)
Вообще 3400 источников, ежесекундно - по объему походит на технологии Big data. Почитайте тут

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

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

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

И всё таки мне кажется Big data это не мой случай, сложно всё там smile
PM MAIL   Вверх
Game-lot
Дата 31.7.2015, 13:43 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 38
Регистрация: 8.11.2007

Репутация: нет
Всего: 2



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

Этот ответ добавлен с нового Винграда - http://vingrad.com
PM MAIL   Вверх
tzirechnoy
Дата 31.7.2015, 14:19 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1173
Регистрация: 30.1.2009

Репутация: 0
Всего: 16



Цитата
Интересно, а big data - это начиная с какого объема?


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

Вот когда у людей четверть тэрабайта важных данных в сутки -- это ужэ, наверное, оно. Особенно если клиенты хотят доступ к результатам, рассчитанным на этих данных on-line.
PM MAIL   Вверх
barmaley4ik
Дата 30.10.2015, 14:22 (ссылка)    |    (голосов: 0) Загрузка ... Загрузка ... Быстрая цитата Цитата


Unregistered











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

Этот ответ добавлен с нового Винграда - http://vingrad.com
  Вверх
barmaley4ik
Дата 30.10.2015, 14:40 (ссылка)    |    (голосов: 0) Загрузка ... Загрузка ... Быстрая цитата Цитата


Unregistered











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

Этот ответ добавлен с нового Винграда - http://vingrad.com
  Вверх
Zloxa
Дата 30.11.2015, 22:50 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Чо?
****


Профиль
Группа: Завсегдатай
Сообщений: 3470
Регистрация: 12.9.2008

Репутация: 11
Всего: 161



Цитата(tzirechnoy @  30.7.2015,  16:35 Найти цитируемый пост)
а писать в файлы самому

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


--------------------
Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile
PM   Вверх
tzirechnoy
Дата 2.12.2015, 15:54 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1173
Регистрация: 30.1.2009

Репутация: 0
Всего: 16



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

Да, а что не так с дурабилити в предложэнной мной схеме с двумя журналами?
PM MAIL   Вверх
Zloxa
Дата 2.12.2015, 21:50 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Чо?
****


Профиль
Группа: Завсегдатай
Сообщений: 3470
Регистрация: 12.9.2008

Репутация: 11
Всего: 161



Цитата(tzirechnoy @  2.12.2015,  16:54 Найти цитируемый пост)
Я просто встрял на слове "ароматность". Что это? Кто это выдумал? Зачем?

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


--------------------
Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile
PM   Вверх
tzirechnoy
  Дата 3.12.2015, 20:53 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1173
Регистрация: 30.1.2009

Репутация: 0
Всего: 16



Нет, сам не догадался. Ну, тут в общем бог бы с ней, с атомарностью: что записалось -- записалось, что недозаписалось -- как и не было.
PM MAIL   Вверх
Zloxa
Дата 3.12.2015, 21:07 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Чо?
****


Профиль
Группа: Завсегдатай
Сообщений: 3470
Регистрация: 12.9.2008

Репутация: 11
Всего: 161



Цитата(tzirechnoy @  3.12.2015,  21:53 Найти цитируемый пост)
Нет, сам не догадался. 

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


--------------------
Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile
PM   Вверх
Google
  Дата 17.7.2019, 11:31 (ссылка)  





  Вверх
Ответ в темуСоздание новой темы Создание опроса
Правила форума "Общие вопросы по базам данных"
LSD
Zloxa

Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:

  • вопросам по СУБД для которых нет отдельных подфорумов
  • вопросам которые затрагивают несколько разных СУБД (например проблема выбора)
  • инструменты для работы с СУБД
  • вопросы проектирования БД
  • теоретически вопросы о СУБД

Данный форум не предназначен для:

  • вопросов о поиске разлиных БД (если не понимаете чем БД отличается от СУБД то: а) вам не сюда; б) Google в помощь)
  • обсуждения проблем с доступом к СУБД из различных ЯП (для этого есть соответсвующие форумы по каждому ЯП)
  • обсуждения проблем с написание SQL запросов, для этого есть форум Составление SQL-запросов
  • просьб о написании курсовой, реферата и т.п., для этого есть Центр помощи или фриланс биржа
  • объявлений о найме специалистов, для этого есть раздел Объявления о найме специалистов

Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение. ;)


Полезные советы:

При написании сообщения постарайтесь дать теме максимально понятное название. В теме максимально подробно опишите проблему. Если применимо укажите: название базы данных и версии (MySQL 4.1, MS SQL Server 2000 и т.п.); используемых язык программирования; способа доступа (ADO, BDE и т.д.); сообщения об ошибках.

Для вставки кода используйте теги [code=sql] [/code].

Литературу по базам данных можно поискать здесь.

Действия модераторов можно обсудить здесь.


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa.

 
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | СУБД, общие вопросы | Следующая тема »


 




[ Время генерации скрипта: 0.0760 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.