Сергей Ковалёв ну и заодно расскажите о проблемах с которыми столкнулись, может действительно не стоит вкладываться в это, мы-то еще маленькие, может пора на asp.net 5 мигрировать, да линуха поднимать, пока не поздно)
Сергей Ковалёв Не могу сказать что у меня 100 серваков этим управляется, с двумя IIS-ами, одним SQL и одним TFS под проект - как-то справляемся (бэкапы, рестарты, всякие деплои нестандартные с CI на TFS на проды), а вас есть что-то революционное под винду? С удовольствием посмотрю)
Андрей хм, а как оно повлияет на ситуацию? Оно б могло скорее помочь прикинуть, сколько до объекта сантиметров, если он в фокусе, но если мы игнорируем глубину (вычисляем ее за счет использования нескольких ракурсов, как делает наш мозг), то тогда без разницы.
Роман Кофф Вот кстати очень близко к вам: habrahabr.ru/post/130300 , тут про машинное стереозрение и соответствующие расчеты.
> Карта глубины может быть получена с помощью специальной камеры глубины (например, сенсор Kinect является своего рода такой камерой), а так же может быть построена по стереопаре изображений.
Часть вашей задачи.
Pavel_Develop
не пользуюсь, это антипаттерн и я вполне обхожусь без него (т.е. помещаю логику в модельные классы). Он появляется от чрезмерного желания разделить приложение на много слоев, отчего некоторые слои в конце-концов мало что толкового делают (пресловутые Business Logic layer и Data Layer).
diver23
> вводить денормализацию тегов что бы ускорить выборку
отметьте на будущее: стандартный цикл разработки структуры БД (там, где есть схема) - нормализация "до упора", денормализация по необходимости для ускорения конкретных (!) запросов. Обычно для 80% запросов нормализованная структура вообще проблемы не составляет, и только 20% и менее самых тяжелых или самых частых (например, отрабатывающих на главной странице) требуют введения избыточных данных.
Pavel_Develop
> Я имел ввиду не маппинг БД и ORM, а маппинг между сущностями Document и Order
что-то совсем непонятно стало. Для маппинга саб-классов на таблицы есть несколько стратегий: single-table inheritance, class-table inheritance concrete table inheritance, single table замапает вам несколько классов на одну таблицу. Это конечно если вы пришли к тому, что вам действительно нужно несколько классов.
@JustSokol
QSet is one of Qt's generic container classes. It stores values in an unspecified order and provides very fast lookup of the values. Internally, QSet is implemented as a QHash (doc.qt.io/qt-5/qset.html#details).
Итак, значит QSet сделан на базе QHash. Конечно, на википедию давать ссылку немного несерьезно, но сейчас поздно уже, я себе позволю) : https://ru.wikipedia.org/wiki/%D0%A5%D0%B5%D1%88-%...
Читаем: Ситуация, когда для различных ключей получается одно и то же хеш-значение, называется коллизией. Такие события не так уж и редки - ... Поэтому механизм разрешения коллизий — важная составляющая любой хеш-таблицы.
И далее перечисляются методы, самые популярные два - вешать на значение хэша список (!) элементов с таким хешем, либо же просто вставлять элементы друг за другом, т.е. искать следующий свободный слот (неважно, что он может потенциально понадобиться другому элементу).
Суть хэш-таблицы - в ускорении поиска, приближении его к O(1) (как, в принципе, и вставок). Точная проверка совпадения обеспечивается дополнительно.
> он сначала по хешу найдет два значения а потом сравнит с каждым и даст ответ
да, разумеется. Там может быть хоть 100 значений на хэш, операция должна выполниться корректно (другое дело - будет выполняться медленнее, чем хочется).
Кстати, внимательно почитайте требования к типу элемента:
- QSet's value data type must be an assignable data type.
- the type must provide operator==()
- must also be a global qHash() function that returns a hash value for an argument of the key's type.
С присвоением понятно, с qHash тоже, обратите внимание на оператор сравнения - никто его не отменял, он по прежнему нужен и должен корректно отрабатывать.
Резюме: проблема поиска хорошего хэша безусловно есть в каждой подобной задаче, однако это вопрос снижения сложности операций поиска/вставки и повышения производительности. После поиска по хэшу всегда будет поиск на точное совпадение (даже если по хэшу найден только один элемент - вдруг это коллизия и у нас не точное совпадение).
Artem да я так его три раза прочел прежде чем ответить, расскажите пожалуйста почему вас так беспокоит случай совпадения конкатенаций. Т.е. есть два вопроса: 1) понимаете ли вы, что уникальный хэш получить невозможно для строк той длины, что у вас есть; 2) непонятно зачем вам уникальный хэш и почему вас так беспокоит его неуникальность в достаточно редком на мой взгляд случае.
Если строки у вас совсем короткие, по 2-3 символа, то тогда совпадать будет почаще, значит пример с именами неудачный.
xfg как правильно заметил Дэн Иванов, до готовой системы разумеется еще далеко, и граблей будет навалом. Я думаю мы бы с вами могли на пару недель сесть и обдумывать одни только проблемы и пути их решения.
Конечно, файлы было бы неплохо разбивать на кластеры, наподобие того как делают обычные ФС, и хэшировать кластеры, а не весь файл, а сами хэши сохранять в метаинфе, и хранить их как i-blockи хранятся в ext, по иерархическому принципу. Тогда файлы можно сильно фрагментировать (по 1 ГБ к примеру), и разбрасывать куски по хранилищам.
Маппинг пространства хешей на ноды можно немного усложнить, и мапать по принципу хэш-таблицы: если на ноду N файл не влазит уже, класть на N+1 (также и искать потом), позже, по достижению критического количества неверных попаданий, перехешировать, увеличивая длину части хэша, по которой определяется номер ноды (вместо первых 3-х байт хеша - первые 4).
Давайте решим, что вам нужно: вы готовы писать свой велосипед и решать все проблемы выше, или вам все-таки нужно готовое решение. Если готовое - вон, Дэн Иванов отлично посоветовал. Амазоновский S3 в конце-концов есть, даже ставить ничего не надо. Или может у вас файлы по 1кб и вам хватит того же Redis?)
@Avery007
> А насколько сильно использование фабрик скажется на производительности?
это обычная функция, т.е. ее вызов должнен быть даже дешевле, чем виртуальный вызов функции в интерфейсе (конечно, если не считать расходы на загрузку DLL в начале работы и прочие дела). А так да, как сказал MiiNiPaa - что туда положите, то там и будет. Смысл в том, что даже если там обычный new, и больше ничего - все равно это важно, т.к. вызов оператора new подразумевает знание РАЗМЕРА объекта (сколько место под поля выделить), а размер объекта в памяти - это по сути часть реализации, т.к. может изменяться при изменении кода реализации. Это вообще отдельная проблема в C++, различные библиотеки применяют различные подходы для ее решения, например Qt использует PImpl, погуглите.
Если вы вызываете new внутри библиотеки, то вызывающему функцию-фабрику НЕ НУЖНО знать о размере объекта, что принципиально важно: вы можете добавить пару полей в ваш ConcreteFooService, и вызывающее приложение перекомпилировать не нужно. Если вы вызывающее приложение делало new, то потребовалась бы его перекомпиляция, т.к. каждый new это выделение КОНКРЕТНОГО фиксированного объема памяти.
Таким образом, в случае использования фабрик такой аспект реализации, как размер объекта, остается в ведении DLL и не "вытекает" наружу, создавая вредные зависимости.
QstoNSadManSad CSS к кнопкам можно было применять и в Qt Widgets, у нас большое приложение с полностью кастомным дизайном и двумя темами - белой и черной, и большая часть кастомизации (не считая, конечно, иконок) сделана с помощью CSS. В Qt Quick в этом плане не хуже, хотя там свой язык стилизации.
> Если человек, который разрабатывает интерфейс программы, знает css, то можно легко и просто изменить полностью весь дефолтный дизайн элементов.
полностью потверждаю эти слова работающим приложением)
> Т.е. можно применять CSS к кнопкам? Есть где-нибудь почитать об этой теме?
в официальных доках вроде все было. Ну или в локальной справке, обычно ей пользуюсь
QstoN Да, Qt Creator не очень силен в этом плане. Однако возможности стилизации в Quick в целом весьма нелохие: doc.qt.io/qt-5/qtquickcontrolsstyles-index.html. Ну или стандартные сэмплы посмотрите.
С учетом того, какая сейчас ниша у C++, я считаю эти инструменты достойным аналогом того же дотнетовского WPF)
Дэн Иванов уточню, что под жизнеспособностью я понимаю определенный уровень надежности, при котором система не развалится и не упрется в архитектурные ограничения на первых этапах использования. Такие решения строятся при точных требованиях (на сотню-другую страниц ТЗ) и тратится определенное время на тестовые нагрузки.
Дэн Иванов видимо у нас разное представление об обмене знаниями на таких ресурсах). Я либо сам буду проверять идеи и советы, которые мне дадут, или спрошу еще 5 человек, прежде чем вкладывать в идею значительные ресурсы.
Т.к. в хэшировании файлов ничего нового нет, как и в хэш-шардинге, не считаю эту идею абсолютно утопичной и непригодной. Автор вообще хотел хоть что-то найти. Если бы он привел N известных распределенных ФС или object-storage, и спросил бы - что из этого применимо для системы с такими-то объемами данных и таким-то дневным трафиком, то конечно в таком контексте идеям не место. А когда пишут "велосипедное облако".. Даже не знаю, как-то само наводит на мысль об экспериментах :D
Через пару месяцев я и сам задам такой вопрос, т.к. в проект понадобится подобное файлохранилище для документов с привязкой к объектам предметной области, и я бы с удовольствием услышал подобный ответ, равно как и ваш совет взять CEPH или эллиптикс.
xfg идея хэшировать контент безусловно не нова (Git), и шардировать по хэшу - тоже (Redis, Mongo), но конечно не факт, что она будет работать для ваших требований (размеры файлов, количество пользователей и т.д.). Все-таки стоит точнее определить требования: решение с поддоменами действительно часто встречается и работает, но это решение, в котором некоторые операции, например изменение файла, довольно сложно реализовать.
На самом деле я сам в поисках подходящего решения аналогичной задачи для следующего проекта, но пока все туманно. У меня правда требования немного другие (привязка файлов не к пользователям, а к объектам предметной области, которые появляются более контролируемым путем, нежели пользователи), но еще важнее поддержка известных протоколов. Необходимость писать клиентское приложение как у Dropbox или Skydrive выглядит не совсем радужно :) Была идея даже BitTorrent Sync попробовать, однако пока от нее отказались - торрентить маленькие файлы очень неудобно.
@ptchol
> систему простенькую
> Эдакое велосипедное облако.
я сделал акцент на этом, видимо тут кроется моя ошибка. Не знаю где вы в этом разговоре увидели что я утверждал что мой вариант хотя бы жизнеспособен, не говоря уж о сравнении с крупными известными системами. Для того, чтобы это утверждать, нужно выполнять исследование, я автору подкинул лишь идею. Автор сделает исследование, если у него промышленная система, или просто попробует реализовать, если задача учебная. Задавая такой вопрос, я был бы рад услышать любые идеи, причем чем больше чем лучше, а вы разве нет? Автор вроде интересовался и организацией хранения тоже, по крайней мере те варианты что он привел в вопросе, говорят об этом.
А то, что на Тостере подобную реальную сложно обсуждать - это статистика, и я, безусловно, в ней разочарован. За те ответы и вопросы которые тут дают и задают, на SO будут банить, простите, по IP.
Можете посмотреть другие мои ответы, если вдруг подумали, что я не пытался изменить это стереотип.
