Автор Тема: Обсуждение и предложения по реализации базы данных проб оборудования  (Прочитано 47075 раз)

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 19 926
    • Домашняя страница
    • Email
Слово база взято в кавычки, т.к. предполагается использование базы в виде обыкновенных файлов, вместо задействования всяких там мускулей, постгрессов и прочей эскуэльщины.

как минимум, глупо не использовать SQLite, ИМХО.
Да ладно! Вон, вчера люди из Citrix были. У них на каждый линуксовый VDI нужно ставить аутентификацию в Active Directory и (внимание!) PostgreSQL для хранения нескольких передаваемых записей реестра. ;)
Подробности: http://docs.citrix.com/en-us/xenapp-and-xendesktop/7-8/install-configure/red-hat-linux-vda.html
Андрей Черепанов (cas@)

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 9 000
Слово база взято в кавычки, т.к. предполагается использование базы в виде обыкновенных файлов, вместо задействования всяких там мускулей, постгрессов и прочей эскуэльщины.

как минимум, глупо не использовать SQLite, ИМХО.

Тут нет таких данных, чтобы использовать базу, пускай и библиотечную. Зато можно запросто использовать инструменты для работы со строками которых вагон и малая тележка. К тому же, не накладываются ограничения на реализацию. А сама структура позволяет миграцию простым копированием (практически). Тем более, что визуализацию можно делать по-разному. Я вот предлагаю использовать готовую свободно распространяемую cms, частью структуры которой и будет база с записями об оборудовании.
PS Мне больше всего требуется помощь по компонентам sender & recipient, т.к. я не совсем представляю с помощью каких компонентов на баше это реализовать, чтобы не требовались лишние компоненты. Фактически, нужен некий довольно-таки простой сервис, слушающий на порту (причем не обязательно на порту 80), отсеивающий запросы, не удовлетворящие формату и маркерам дистрибутива (возможно, ещё чему-то, чтобы как-то определенно совершенно сказать, что проба отправляется не из виртуалки, к примеру и на машине установлен какой-либо из дистрибутивов альт линукс). Ну и помимо этого, хорошо бы определиться с остальными неизвестными, чтобы задача техническая (по написанию непосредственно кода) стала доступной любому желающему.

Оффлайн neobht

  • Завсегдатай
  • *
  • Сообщений: 390
SQLite - это по сути и есть текстовый файлик и реализованный быстрый поиск по строкам через хеши и индексы.

А реализацию сервера на bash на порту - это тоже какое-то из ранга "нахлобучки". Для этих целей лучше всего подошел бы Python. Тем более в нем уже стандартно идет HTTP и прочие серверы, которые слушают на порту данные.

Поэтому я бы рекомендовал использовать Python+SQlite. Тогда это имеет шансы быть проектом группы, а не только одного человека.

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 9 000
SQLite - это по сути и есть текстовый файлик и реализованный быстрый поиск по строкам через хеши и индексы.
Требование иметь библиотеку - зло в том случае, когда этого можно не делать и не привязываться к базам данных. Ну не нужно для библиотеки (а hcl в том виде, что я предлагаю и есть библиотека с очень очень редкой записью - в основном это чтение, все остальное реализовывается через content-provider) это, не нужно. Сейчас наиболее важно определиться с критериями уникальности пробы, чтобы независимо от количества проб на одной машине, по этим критериям получать железно неизменный результат. Здесь нужна помощь, т.к. все файлы перелопачивать и делать все на ощупь очень не хотелось бы - слишком по времени долго выйдет. Вместо sqlite предлагается (если вы уж такой любитель баз) использовать нормальную файловую систему с кэшированием (данных, кстати, в этой базе будет мало по объему и оно отлично будет кэшироваться на любом хостинге, даже с небольшим объемом памяти). Использование библиотеки увеличит потребление, а питон увеличит это потребление до неприемлемого (ввиду того, что это все можно наверняка написать на тех же сях, пускай и с использованием какой-нибудь легкой библиотеки, которая может очень такое быть уже входит в большинство дистрибутивов).
Баш я привел только потому, что лично я ничего другого особо не знаю, и писать все это вряд ли буду. Здесь нужна помощь, но сначала критерии, а потом реализации. И я настаиваю на том, что база здесь абсолютно ни к чему. Я сомневаюсь, что база будет сильно быстрее операций над строками даже теми же гнутыми утилитами, которые есть на любой уважающей себя linux системе, в том числе и на простом сервере без графической оболочки. Тем более, что спешка здесь как раз ни к чему - все пробы обрабатывает другой компонент. Вот здесь можно и питон приложить, если уж так хочется или перл, или предложите что-нибудь на ваш выбор. Короче говоря, тут есть выбор инструментария. Мне просто в силу недостаточности знаний увидеть, что лучше подойдет здесь, сходу трудно. Но это точно никак не мешает попробовать разные реализации.

Оффлайн neobht

  • Завсегдатай
  • *
  • Сообщений: 390
Может быть тогда еще проще добавить AltLinux в hwprobe, что создана для Роса? Или хочется свое именно и у себя?

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 9 000
В случае, если вдруг окажется, что быстродействия недостаточно (или ещё найдутся какие-то причины, которые будут однозначно подталкивать к использованию базы), то на базу вполне можно всю перетащить (достаточно затолкать данные из файла[ов] в базу, но, имхо, это все как 5 колесо в телеге) не особо напрягаясь. Придется немного подкорректировать последний компонент, но там пхп, так что особых проблем, я думаю, тоже не будет. Инструментария на этот счет вагон и малая тележка. Никто не запрещает и свое написать, если захочется из доступных компонентов (как это в росе сделали, как они заявляют, хотя мы и не можем проверить).

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 9 000
Может быть тогда еще проще добавить AltLinux в hwprobe, что создана для Роса? Или хочется свое именно и у себя?
Вопрос сборщика не принципиален. Но тут другой момент. Можно поддерживать несколько решений. В каждом из них свой формат вывода и придется писать парсеры, которые вытаскивают нужную информацию. На мой взгляд, лучше заложиться на что-то одно, где формат известен и меняться вряд ли будет. И это, конечно, альтовый system-report. При всем уважении, росовская утилита может поменять формат под свои требования (причины могут быть разные совершенно). Вопрос исключительно в том, чтобы все работало при любых раскладах. Но это не мешает добавить поддержку альта куда угодно, лишь бы оно выдавало требуемые данные и в требуемом формате. Наверное, так. Сейчас весь вопрос в этих форматах обмена между sender и recipient, как и в самой их реализации в коде. На первых порах, в принципе, можно и на питоне написать (на безрыбье и рак - рыба).

Оффлайн neobht

  • Завсегдатай
  • *
  • Сообщений: 390
Чтобы формат не менялся с бухты барахты, поддержка специфики Альта должна быть в апстриме, подобно Роса и тогда все становится понятным в случае изменения форматов.

А получается, что каждый куралесит себе свое и в итоге получается много всего и разного и содержащее определенное количество ошибок.

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

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 19 926
    • Домашняя страница
    • Email
Чтобы формат не менялся с бухты барахты, поддержка специфики Альта должна быть в апстриме, подобно Роса и тогда все становится понятным в случае изменения форматов.
А где апстрим для программы сбора данных?
Андрей Черепанов (cas@)

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 9 000
А получается, что каждый куралесит себе свое и в итоге получается много всего и разного и содержащее определенное количество ошибок.
А так и будет. В росе свои пробы (по дистрибутивам), у нас свои будут и чужих нам не надо. Мы же не претендуем на международную базу вообще всего оборудования под всеми возможными дистрибутивами. Мы учитываем только работу оборудования под конкретным дистрибутивом, т.к. это можно поддерживать даже своими силами (правда это требует усилий и затрат, но это другой разговор). Это точно так же, как роса не ответит за работу альт линукс и наоборот. По-моему, все логично. Запросы к базе у разных дистрибутивов будут различные. И, опять же, невозможно всех под одну гребенку подогнать, потому что целеполагание будет в любом случае отличаться. Кому-то свистелки нужны, кому-то свистелки наоборот до фени и т.д. и.т.п.

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 9 000
Чтобы формат не менялся с бухты барахты, поддержка специфики Альта должна быть в апстриме, подобно Роса и тогда все становится понятным в случае изменения форматов.
Это опять-таки от целеполагания зависит (чего хотят получить и это спрогнозировать за других нельзя, как нельзя залезть в голову людям, которые за развитие дистрибутива отвечают). Захотят базу перетрясти под другие требования и вот вам смена формата и т.п. К тому же, их клиент заточен под их базу и никто туда добавлять поддержку других дистрибутивов не будет скорее всего (нет смысла). А код сервера вообще закрыт.

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 251
  • Учиться .... Телепатами не рождаются, ими ....
    • Email
Чтобы формат не менялся с бухты барахты, поддержка специфики Альта должна быть в апстриме, подобно Роса и тогда все становится понятным в случае изменения форматов.

Что-бы формат не менялся по воле апстрима, должен быть его общепринятый стандарт. Имеется ли такой? Нет - мы вольны в своих намерениях. Формат важен, если-бы была возможность обмениваться между собой базами поддерживаемого оборудования между различными разработчиками дистрибутивов. Покак такой возможности нет - каждый будет вариться в своём котле.

Оффлайн neobht

  • Завсегдатай
  • *
  • Сообщений: 390
Апстрим на стороне Роса. С ним и нужно договариваться. Единое целеполагание в данном случае возможно. Из доработок, наверное, даже и делать ничего не нужно. Тип дистрибутива в пробе есть. Вебмордочку нарисовать тоже не сложно.

А вообще помимо sqlite+python в современном решении должен быть bootstrap, формат обмена должен быть в json. Отправил запрос json и получил ответ json. Потом либо мобильное приложение, либо вебморда, либо простейший консольный клиент уже полученный от сервера json обрабатывает.

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 9 000
Апстрим на стороне Роса. С ним и нужно договариваться.
С какой целью ? Сервер закрыт и нам неподконтролен. Лично меня как инициатора подобное не устраивает. Более того, меня не совсем устраивает их подход. Это, если кратко, развернуто смысла нет говорить, т.к. вывод - никто ни с кем не собирается договариваться, т.к. нет объективно предпосылок к этому. Сам по себе клиент не интересен абсолютно в при условии, что сторона сервера и морда (как и структура данных) будут отличными как от реализации росы, так и от реализации другой публичной базы, ссылка на которую есть в теме вк.
А вообще помимо sqlite+python в современном решении должен быть bootstrap, формат обмена должен быть в json. Отправил запрос json и получил ответ json. Потом либо мобильное приложение, либо вебморда, либо простейший консольный клиент уже полученный от сервера json обрабатывает.
Зачем такие сложности ? Там передавать-то особо ничего не надо. Готовый архив, условно, передается и хэш. Все (это касается взаимодействия клиента отправляющего пробу и приемной стороны сервера). Зачем здесь json, зачем мобильное приложение, когда веб-клиенты (веб-браузеры) сейчас везде, даже в телефонах простых есть, веб морда и будет показывать все извлеченное и структурированное так, как нам надо и как это могут воспринять браузеры на стороне клиентов, которые будут по базе что-то искать или просто просматривать. И json здесь вроде бы вообще не нужен. У меня складывается ощущение, что вы не понимаете блок-схему и почему все нарисовано именно так, а не иначе (и написано пусть и с ошибками, но именно так, как написано).

Оффлайн sb

  • Модератор глобальный
  • *****
  • Сообщений: 9 000
Единственный нюанс, который все же хотелось бы уяснить (выяснить). Нужно ли в базу сохранять хэш. С одной стороны, это вроде бы и не нужно (анонимизация полная), с другой стороны, по этому хэшу можно предоставить возможность отправляющему редактировать комментарии (или добавлять их) к своей пробе по хэшу. Поскольку в представленной схеме пока не предполагается доступ кого-либо к базе в плане изменений, то может показаться, что нет необходимости предоставлять автору пробы возможность добавлять к ней комментарий в любое время после того, как он пробу отправил (либо же одновременно с пробой). С другой стороны, если будут люди, желающие сами вносить комментарии и пометки к пробам (или к конкретному оборудованию), то доступ по хэшу становится невостребованным. В этом случае возможность изменений можно и нужно организовывать через content-provider.