des1roer: Есть случаи, и их много, когда все данные помещаются в кеш, ну и зачем тогда держать две базы? И есть случаи, когда и сам кеш не нужен, ну и нафиг его.
PS. Прочитал по вашим ссылкам статьи из хабра, это как раз случаи неправильного выбора кувалды. Тем более они и сами пишут, что данные - реляционные, ну и зачем, собственно их понесло в монгу? С другой стороны у нас и монга и реляционка и где-то просто файлы конфигурации. Вот про файлы конфигурации у меня может быть рассказ "как я ушел с MySQL на файлы json"!
Из поиска мы получаем набор PK и/или FK, поля соответствия, релевантность и т.д. Если данных для отображения достаточно и не нужно лезть в базу, то их и используем. Если нужно что-то догрузить из базы - догружаем, сверяем, аккумулируем и т.д.
des1roer: Извиняюсь, наверное меня не совсем правильно поняли. Обычно "поиск" применяют так: есть база данных, реляционная или нет - без разницы, пусть будет реляционная. Рядом с ней стоит "поиск", как только что-то изменяется в связанных таблицах базы, асинхронно обновляются данные в "поиске". Нетипичные и полнотекстовые запросы делаются через "поиск", а вся остальная работа ведется в базе данных.
В этом случае получаем очень много преимуществ, фактически недоOLAP к нашим данным. Обновлять данные в "поиске" можно разными путями, как на каждый чих, так, например, и раз в полчаса по изменениям.
Еще раз, я не говорю "выкиньте свой SQL", я говорю "попробуйте проиндексировать свои данные не в SQL"! И заметьте, я не наставиваю, где эти данные должны храниться, в файлах, логах, блобах или таблицах...
des1roer: Не, правильный поиск это хорошо. Например у меня есть датчик с полем HWANALOG="SIMATIC", есть датчик с полем HWPROTOCOL="SIMATIC", есть датчик PRODACTION="SIMATIC", так вот по слову SIMATIC я сразу найду все три датчика. В вашем же случае нужно будет отдельно, прямо или косвенно опрашивать эти поля.
Да и я знаю про провязочные таблицы, но уж поверьте, это совсем не легко, осуществлять по ним поиск.
И да, ничуть не умаляю SQL, более того, в своем ответе написал, что база данных как бы желательна (но не необходима). Sql/nosql, неважно. Но положив данные из базы (например) в правильный поисковик, уверяю, получите гораздо больше в плане поиска, а здесь как раз он и нужен.
Э???? А как сделать так, что два датчика разных производителей имеют разный набор характеристик? Как базу делать под это будем? А как потом искать по 10-20 характеристикам сразу и по трем четырем производителям? Тут автор топика правильный вопрос задает! Мы что под каждый датчик свою таблицу строить будем? SQL, оно, немного не того... для данной задачи.
Подытожу. Хотите чисто и без проблем. Собирайте свой комп (или берите HP) и ставьте debian/fedora/ubuntu server + KVM и управлялкой WebVirtmgr. Хотите энтерпрайзненько - exsi (будет абсолютно тоже самое + vendor lock от vmware). Хотите просто и со вкусом - оставайтесь на макосе и ставьте параллели или vmware. По ресурсам, производительности и функциональщине все будет в пределах 2-3% максимум!
Это я заявляю, как активный пользователь всего выше названного.
Ну а если хотите правильно, то сразу смотрите на железки с поддержкой SV-IOV, в частности адаптеров ethernet для самосборки и для покупного железа.
Я бы для дома и экскрементов остался бы на макмини и параллелях (у самого дома и iMac и Air и два макбука с параллелями). На работе куча серверов с KVM, на которых около 200 человек трудятся.
Да нет их чистых, нет и все тут! Я же написал, что все, абсолютно все гипервизоры работают под управлением операцоинки, будь то hyperv (windows) или exsi и xen (тот же линукс. И еще нужно посмотреть, сколько ресурсов отжирает линукс в exsi, против чистой макоси. Я так думаю, что поболее, загружая кучу служб для удаленного администрирования и всяких интерфейсрв типа iscsi инициаторов, nfs, vsfs и абсолютно ненужного вам энтерпрайзного барахла.
Вообще-то и параллели и KVM - именно гипервизоры, использующие соответствующие ресурсы процессора для виртуализации, как и xen и vmware и virtualbox. Так что это именно в вашем понимании "baremetal". И ведь никто не говорит, что и ксен и вмваре работают на линуксе, собственно как и kvm. И чем плохо ядро mach для этих целей? Это совсем не jail и даже не близко! Аппаратная виртуализация.
Мультикаст = локалка. По другому никак! С другой стороны, если у клиента уже есть старый кеш серверов, то он достаточно быстро будет старотовать. фактически так делает битторрент, и не только...
И да, ну нет, нету в глобальном интернете мультикаста! Что-то нам обещает переход на IPv6 с его anycast, но мне кажется, то провайдеры будут его закрывать... (очень кажется)
А обязательно знать каждого? может быть достаточно знать 3-10 рабочих? Да сам механизм достаточно простой, координации никакой не нужно, просто рассылаем рандомно 5-6 серверам свой весь свой список. Через некоторое время все сервера будут знать всех.
Виталий Пухов: Увы, IP-протокол, который маршрутизируется в глобальной сети, устроен так, что нужна точка входа или несколько точек.
Все P2P сети устроены аналогично. Есть изначальный пул точек входа, с которых мы получаем "последние зерегистрированные IP-адреса", далее проходим по ним и подключаемся к живому серверу.
Технически, клиенты в P2P являются и серверами, тогда можно у любого клиента спросить список других клиентов.
Но при запуске всё равно нужно знать хоть пару-тройку живых серверов.
