Базы данных. С чего начать?

[Артем]

 Всем добрый день/ночь.

1.  Есть необходимость разработать (или найти подходящий существующий) формат для хранения огромного количества данных (измерений из аппаратуры и кучи датчиков), которые записываются по мере поступления (~5 гигов в час), а потом эти данные (и записи от датчиков тоже) быстро просматривать.

2.  Есть желание сделать так чтобы слова "SQL",  "Oracle",  "mySQL",  "SQLServer" перестали быть для меня просто набором букв.

Вопрос:
1.  Что можно почитать про теорию баз данных (про теорию хранения данных, если есть такая)?

2.  Если бы меня спросили "С чего начать в изучении  Си ?", я бы ответил "Г. Шилдт + VC 6.0".
    А с чего мне начать для изучения "программирования баз данных"?     например < "SQL",  "Oracle",  "mySQL",  "SQLServer" > ?

[RXL]

MySQL: мануал на их сайте - вполне толковый. На www.mysql.ru можно посмотреть перевод (довольно старый) мануала.

[Hooter]

Для начала изучения языка SQL есть отличная книга Мартина Грубера "Понимание SQL". Лучше купить, чтоб под рукой была, но в сети тоже есть.
http://linux.yaroslavl.ru/docs/prog/sql/index.html

На www.firststeps.ru есть раздел SQL by step, но там используют MS SQL Server и  Oracle.

Инфа по БД есть и на https://club.shelek.ru/view.php?id=15

[Артем]

  Спасибо за ссылки, пошел изучать...

Насчет первого моего вопроса (теории хранения данных), насколько вообще реально уже во время записи сжимать данные, да еще так, что бы потом их можно было быстро прочитать.
 Я поясню. С аппаратуры приходят строки данных. Диапазон данных 0...65000. Вроде надо 2 байта. Но я заранее знаю, что по сторке данные меняются по определенному закону ( например, y=exp(x) ), и могу писать в файл не сами данные, а отклонения данных от предполагаемого закона. Допустим, я нашел настолько хороший закон, что все отклонения укладываются в 1 байт (0...255). Ну и плюс сам закон тоже надо записать.
 А теперь, возьмем и для каждой строки данных расчитываем закон (на основе предыдущих строк), и получается что для каждой строки данные пишуться относительно своего закона. Вроде все сжимается уже в два раза.

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

Понимаю, что несколько путанно ставлю вопрос, попробую сформулировать четче:

 Как мне на этапе разработки формата данных оптимизировать хранения этих данных?
Критерии оптимизации (по мере убывания важности критерия): скорость записи (что бы успевать писать несколько мегов/сек), объем, скорость считавания данных, возможность последующего сжатия (в идеале на порядок сжимать надо   ).



P.S. Не судите строго, вся-таки я пишу в раздел, цитирую, "для тех кто плохо понимает- что ему спросить" .



 

[RXL]

Я думаю, что "несколько мегов/сек" в базу врятли запишешь.
Делай сжаатие блока данных до записи в базу. Алгоритм подбирай подходящий к природе данных и требованиям сохранности (точность востановления). У тебя ведь вопрос не по БД, а по алгоритмам сжатия получается...

Если ф-ия примено известна, то можно и вычитать ее и делить на нее. Это, конечно, требует чтобы ф-ия была синхронна по фазе обрабатываемому сигналу. Блок отсчетов аналогового процесса можно перевести из временной системы в частотную и загрубить результат (либо отбросить менее ценные состовляющие) - как делается в mpeg. Выбор целиком за тобой. Результат, если его размерность не кратна 8-ми битам, можно еще пожать по Хафману.

[Alf]

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

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

В-третьих, что означает "быстро просматривать" данные, поступающие со скоростью 5 гиг в час, или примерно 1.5 мега в секунду? Глазами следить, как мельтешат цифры? В сыром виде такая информация просто не может быть воспринята человеком. Имеет смысл вычислять какие-то производные величины (среднее, отклонение от среднего, спектр или что еще в этом духе), а уже их заносить в базу. Если обработать сигнал с умом, то данных получится не так уж много, и реляционная база вполне потянет (если, повторюсь, ее использование вообще оправдано для данной задачи).

В последнем случае имеет смысл подумать насчет использования OLAP.

[Артем]

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

Во-вторый, моя "гениальная" идея -- в одном посте задать два вопроса принесла свои плоды, т.е. запутала ответы на оба вопроса.
Постораюсь исправиться:
 
 1. На вопрос про базы данных ("с чего начать?"), я получил исчерпывающий ответ. Спасибо

 2. Теперь забываем слова "базы данных". И ведем речь только о записи в файл больших объемов данных.

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

  Кстати, RXL, благодаря твоему посту, я понял чего я хочу.
  Я хочу сжимать данные "на лету" со скоростью ~2 мега в секунду, без потери информации, и желательно в несколько раз!!! А потом еще то, что получилось успевать писать на диск. Это возможно?

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


   

[Alf]

Я хочу сжимать данные "на лету" со скоростью ~2 мега в секунду, без потери информации, и желательно в несколько раз!!! А потом еще то, что получилось успевать писать на диск. Это возможно?

Писать на диск примерно 2Мб в секунду в принципе вполне реально, современные диски дают внутреннюю скорость обмена примерно на порядок выше, поэтому запас будет. Причем такой темп выдержат на только дорогие SCSI-модели, но и более дешевые IDE и SATA, которые все ближе подтягиваются к первым по параметрам. Если бюджет проекта позволяет, хорошо бы взять контроллер с аппаратно реализованным кэшем, это позволит сгладить влияние задержек при позиционировании головок.

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

Чтобы хорошо сжимать данные, нужно наперед знать о них достаточно много, только в этом случае сжатие получится достаточно сильным. Кроме того, сжатие на лету затруднено еще и тем, что качество сжатия определяется размером буфера. Например, это хорошо видно при работе архиватора RAR, который явно показывает состояние своего буфера. Обычно видно, что он просматривает данные далеко вперед. Поскольку мы предсказывать будущее не можем, то и жать на лету не получится, только с приличным опозданием.

Кстати, наверное, надо бы почитать как видео сжимается, и как там реализован поиск.

Как правило, при сжатии звука и изображения используются не те же самые алгоритмы, что и для архиваторов общего назначения. Архиваторы только устраняют избыточность данных, однако это процесс обратимый. Развернув архив, мы получаем исходный файл с точностью до бита. В случае со звуком (изображением) картина иная. При декомпрессии мы получаем не копию исходного звука, а лишь звук, который довольно похож на исходный, причем чем выше степень сжатия, тем отчетливее отличие от оригинала (каждый наверняка знает, что такое bitrate). При этом используются особенности восприятия звука человеческим ухом, например, слабая чувствительность к фазовым искажениям по сравнению с амплитудными и частотными или слабая различимость тихих звуков на фоне громких и т.д.

С изображением примерно та же история. Глаз не особо заметит подвох, если немного изменить цвет мелких деталей либо вообще слить их с фоном. Точно так же можно не передавать детали быстро движущихся фрагментов, они все равно будут смазаны за счет инертности глаза. Эти и множество других трюков позволяют на порядки уменьшить потоки видео/аудиоданных при удовлетворительном восприятии человеком.

Вряд ли эти фокусы помогут при работе с экспериментальными данными, где подобные вольности недопустимы.

[Артем]

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

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

  Насколько верное следующее рассуждение:

  Каким-то образом я получил кривую будущих данных, и каким-то образом я знаю что будущие данные не будут отклоняться от этой кривой более чем на 1000 единиц. Если исходно я трачу по 16 бит на отсчет,а теперь мне надо тратить 10 бит, то сжатие получается в 1.6 раза. А если данные бутут отклоняться от этой кривой на 4000 (12 бит надо), то коэфициет сжатия уже 1.3. 
 Верно?  Если да, то этот вариант действительно неустраивает. Получаются довольно большие затраты на получение "кривой будущих данных", к тому же, наверняка 16 бит записать (считать) на диск  будет быстрее чем 10 или 12 бит.

А сжатие с потерями для этих данных действительно не допустимо. По-крайней мере на этапе сбора.

[Артем]

  Кстати, Alf, а может есть еще какое-то "знание" о данных, которое мне поможет сжать их.


Т.е. я хочу спросить:
  Какая информация о данных, может помочь сжать их?

Вдруг такая инфа у меня есть, а я просто не знаю что ее можно использовать.

[Alf]

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

Или сигнал меняется медленно, не более чем на +/-N делений в единицу времени. В этом случае можно хранить не отсчеты целиком, а разность между текущим и предыдущим отсчетами. Чтобы не накапливалась ошибка, периодчески вставлять отсчеты полностью, а потом только разности до следующего полного отсчета.

Если это, к примеру, синусоида, достаточно хранить 4 отсчета на период: минимум, максимум и пересечения нулевой оси.

В общем, чем больше знаешь о сигнале заранее, тем меньше придется писать в файл.

[PAHAN]

Прочитав, чего  Вы все тут натворили возникла тупая мысль -- а нет ли нужного вам функционала в уже готовой SCADA системе? Может есть смысл поискать готовое решение, а не писать костыли и подпорки

[Alf]

Полагаю, автору нужен более содержательный совет, вроде "готовая система X обеспечивает функционал Y и при этом стоит Z долларов (загружается бесплатно с такого-то URL). Искать можно долго, и не факт, что найденное в результате не окажется тем же костылем, только инкрустированным золотом снаружи.

Есть конкретное предложение?

[Артем]

 К тому же я не знаю что такое SCADA система

Если будет ссылочка на место где пронее можно будет почитать--буду премного благодарен

[Alf]

К тому же я не знаю что такое SCADA система

Не более чем аббревиатура (Supervisory Control and Data Acquisition). Типа "веревка есть вервие простое", если за умным названием ничего не стоит, ценность рекомендации стремится к нулю.

[PAHAN]

Полагаю, автору нужен более содержательный совет, вроде "готовая система X обеспечивает функционал Y и при этом стоит Z долларов (загружается бесплатно с такого-то URL). Искать можно долго, и не факт, что найденное в результате не окажется тем же костылем, только инкрустированным золотом снаружи.
Есть конкретное предложение?

Не имея нинформации о технологичеком процессе, датчиках, алгоритмах управления "ценность рекомендации стремится к нулю"

Можно посмотреть сюда http://www.kaskad.elara.ru/products.htm
маленькое введение
http://lab18.ipu.rssi.ru/projects/conf2004/2/010%20%D0%94%D0%BE%D0%BA%D0%BB%D0%B0%D0%B4%20(%D0%91%D0%BE%D0%BB%D0%BE%D0%BD%D0%BA%D0%B8%D0%BD).htm
оффтопик уже пошел

[Артем]

Спасибо, PahanK.
 Я посмотрел ссылки, теперь по крайней мере буду знать что есть такие системы.

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

Видеосъмку можно назвать  "технологическим процессом"?