Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Базы данных. С чего начать?  (Прочитано 32525 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Артем
Опытный

nz
Offline Offline
Пол: Мужской
Beware the wolf in sheep's clothing.


« : 29-09-2005 12:28 » 

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

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

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

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

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



Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 30-09-2005 07:42 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Hooter
Опытный

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 30-09-2005 10:10 » 

Для начала изучения языка 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
« Последнее редактирование: 30-09-2005 10:13 от Hooter » Записан
Артем
Опытный

nz
Offline Offline
Пол: Мужской
Beware the wolf in sheep's clothing.


« Ответ #3 : 30-09-2005 13:07 » 

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

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

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

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

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



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



 


Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4 : 03-10-2005 16:19 » 

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

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Alf
Гость
« Ответ #5 : 03-10-2005 19:59 » 

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

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

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

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

nz
Offline Offline
Пол: Мужской
Beware the wolf in sheep's clothing.


« Ответ #6 : 04-10-2005 14:10 » 

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

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

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

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

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

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


   
Записан
Alf
Гость
« Ответ #7 : 04-10-2005 19:12 » 

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

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

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

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

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

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

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

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

nz
Offline Offline
Пол: Мужской
Beware the wolf in sheep's clothing.


« Ответ #8 : 07-10-2005 08:14 » 

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

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

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

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

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

nz
Offline Offline
Пол: Мужской
Beware the wolf in sheep's clothing.


« Ответ #9 : 07-10-2005 08:16 » 

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


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

Вдруг такая инфа у меня есть, а я просто не знаю что ее можно использовать.
Записан
Alf
Гость
« Ответ #10 : 07-10-2005 10:53 » 

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

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

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

В общем, чем больше знаешь о сигнале заранее, тем меньше придется писать в файл.
Записан
PAHAN
Гость
« Ответ #11 : 21-10-2005 11:07 » 

Прочитав, чего  Вы все тут натворили возникла тупая мысль -- а нет ли нужного вам функционала в уже готовой SCADA системе? Может есть смысл поискать готовое решение, а не писать костыли и подпорки Улыбаюсь
Записан
Alf
Гость
« Ответ #12 : 21-10-2005 11:51 » 

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

Есть конкретное предложение?
Записан
Артем
Опытный

nz
Offline Offline
Пол: Мужской
Beware the wolf in sheep's clothing.


« Ответ #13 : 21-10-2005 15:23 » 

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

Если будет ссылочка на место где пронее можно будет почитать--буду премного благодарен Ага
Записан
Alf
Гость
« Ответ #14 : 21-10-2005 22:03 » 

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

Не более чем аббревиатура (Supervisory Control and Data Acquisition). Типа "веревка есть вервие простое", если за умным названием ничего не стоит, ценность рекомендации стремится к нулю.
Записан
PAHAN
Гость
« Ответ #15 : 22-10-2005 09:43 » 

Полагаю, автору нужен более содержательный совет, вроде "готовая система 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
оффтопик уже пошел
Записан
Артем
Опытный

nz
Offline Offline
Пол: Мужской
Beware the wolf in sheep's clothing.


« Ответ #16 : 25-10-2005 07:25 » 

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

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

Видеосъмку можно назвать  "технологическим процессом"?
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines