Если допустить что есть классы вещей(от более частых к более редким):
серые, зеленые, синие, фиолетовые, красные.
Каждый класс имеет также свои подклассы — различный мусор, зелья, шмотки.
Итого имеем 15 категорий в которых разные шансы выпадения, причем они могут иметь привязку к определенным модам, событиям, учитывать уровень игрока, а также количество уже существующих таких шмоток в игре(что бы не приводить к утрате ценности вещей).
А еще понадобится подкрутить рейты(может так получиться что рейты завышены или занижены)
Из за этого ваш подход становится неудобным, и вы прийдете к «мешкам» которые по сути будут тем же самым что вы написали, с тем отличием что условия могут меняться на лету, тем более проще видь в БД писать вещи и вероятности их выпадения, нежели хардкодить, или даже выносить в конфиг.
Это директория в почте к которой можно дать доступ более чем 1 аккаунту, например можно делать public namespace для отдела и ввесь отдел будет видеть все письма которые к примеру можно перемещать туда с помощью sieve
Вес — никто видь не задумывается что самое тяжелое это батарея, но почему то все хотят что бы была как можно большая автономность.
Размеры — батарея, охлаждение, компоновка — вуаля, и мы уже не вложимся в требования, приходится увеличивать размеры, или уменьшать фичи, или жертвовать качеством.
Конский ценник — уверен что то что описано в посте будет стоять не намного дешевле, нужно видь учитывать что он предназначен для трудных условий, на него нужно дать гарантию, не говоря об отбраковке при производстве, продаваться он будет хуже чем гламурный какой то, естественно все накладные расходы лягут именно на небольшую партию, нужно не забывать также о необходимости проведения сертификации, да и вопрос сколько опытных образцов нужно сломать что бы добиться нормальной слаженной работы всех фич и удостовериться что он хотя бы доработает до конца гарантии.
Если очень грубо docker это образ в котором упаковано все зависимости которые нужны для приложения которое вы запускаете в контейнере, когда вы запускаете контейнер запускается 1 приложение, которое использует все зависимости именно из контейнера.
С первого взгляда можно подумать что контейнеры это продвинутый chroot хотя это и не так, но с chroot общего больше чем с виртуалками
поиск и вывод 100 писем из 16000 найденых(пагинация в веб морде) поиском на запрос *777*(поиск проводится по всем полям from, to, subj, body, headers..etc) в директории в которой всего около 350тыс писем заняло 10секунд.
поиск без * около 1.5с, для нас это допустимо
да, прошу прощения, чего то теги порвало.
отказались от этого: filter class="solr.EdgeNGramFilterFactory" minGramSize="1" maxGramSize="40"
размер индекса уменьшился в 10 раз, но так как из за этого перестало искать вхождения, то пришлось пропатчить довекот, вот этим патчем: — dovecot-2.2.33.2/src/plugins/fts-solr/fts-backend-solr.c 2017-10-05 13:10:44.000000000 -0400
+++ dovecot-2.2.33.2/src/plugins/fts-solr/fts-backend-solr.c 2018-02-20 05:10:33.192433172 -0500
@@ -63,7 +63,7 @@
unsigned int truncate_header:1;
};
static bool is_valid_xml_char(unichar_t chr)
{
это позволило в поисковых запросах использовать *(0 или более символов) и ?(1 символ), время поиска почти не изменилось
еще поле user у меня имеет вот такой вид, без нее поиск в public namespaces не работал нормально:
field name=«user» type=«string» indexed=«true» stored=«true» required=«false» default=""
ps: 1500000 писем, размер индекса менее 6гб.
/>
От этого отказались что позволило снизить скорость индексации и размер базы solr
для того что бы искать вхождения пересобрали dovecot что позволило искать вхождение с помощью * и?
Украина — у отца есть возможность взять декретный отпуск(по уходу за ребенком до 3х лет) вместо матери.
серые, зеленые, синие, фиолетовые, красные.
Каждый класс имеет также свои подклассы — различный мусор, зелья, шмотки.
Итого имеем 15 категорий в которых разные шансы выпадения, причем они могут иметь привязку к определенным модам, событиям, учитывать уровень игрока, а также количество уже существующих таких шмоток в игре(что бы не приводить к утрате ценности вещей).
А еще понадобится подкрутить рейты(может так получиться что рейты завышены или занижены)
Из за этого ваш подход становится неудобным, и вы прийдете к «мешкам» которые по сути будут тем же самым что вы написали, с тем отличием что условия могут меняться на лету, тем более проще видь в БД писать вещи и вероятности их выпадения, нежели хардкодить, или даже выносить в конфиг.
Размеры — батарея, охлаждение, компоновка — вуаля, и мы уже не вложимся в требования, приходится увеличивать размеры, или уменьшать фичи, или жертвовать качеством.
Конский ценник — уверен что то что описано в посте будет стоять не намного дешевле, нужно видь учитывать что он предназначен для трудных условий, на него нужно дать гарантию, не говоря об отбраковке при производстве, продаваться он будет хуже чем гламурный какой то, естественно все накладные расходы лягут именно на небольшую партию, нужно не забывать также о необходимости проведения сертификации, да и вопрос сколько опытных образцов нужно сломать что бы добиться нормальной слаженной работы всех фич и удостовериться что он хотя бы доработает до конца гарантии.
Например типа такого:
www.dell.com/ua/business/p/latitude-12-7214-2-in-1-laptop/pd
С первого взгляда можно подумать что контейнеры это продвинутый chroot хотя это и не так, но с chroot общего больше чем с виртуалками
поиск без * около 1.5с, для нас это допустимо
отказались от этого:
filter class="solr.EdgeNGramFilterFactory" minGramSize="1" maxGramSize="40"размер индекса уменьшился в 10 раз, но так как из за этого перестало искать вхождения, то пришлось пропатчить довекот, вот этим патчем:
— dovecot-2.2.33.2/src/plugins/fts-solr/fts-backend-solr.c 2017-10-05 13:10:44.000000000 -0400
+++ dovecot-2.2.33.2/src/plugins/fts-solr/fts-backend-solr.c 2018-02-20 05:10:33.192433172 -0500
@@ -63,7 +63,7 @@
unsigned int truncate_header:1;
};
-static const char *solr_escape_chars = "+-&|!(){}[]^\"~*?:\\/ ";
+static const char *solr_escape_chars = "+-&|!(){}[]^\"~:\\/ ";
static bool is_valid_xml_char(unichar_t chr)
{
это позволило в поисковых запросах использовать *(0 или более символов) и ?(1 символ), время поиска почти не изменилось
еще поле user у меня имеет вот такой вид, без нее поиск в public namespaces не работал нормально:
field name=«user» type=«string» indexed=«true» stored=«true» required=«false» default=""
ps: 1500000 писем, размер индекса менее 6гб.
От этого отказались что позволило снизить скорость индексации и размер базы solr
для того что бы искать вхождения пересобрали dovecot что позволило искать вхождение с помощью * и?
патч dovecot
— dovecot-2.2.33.2/src/plugins/fts-solr/fts-backend-solr.c 2017-10-05 13:10:44.000000000 -0400
+++ dovecot-2.2.33.2/src/plugins/fts-solr/fts-backend-solr.c 2018-02-20 05:10:33.192433172 -0500
@@ -63,7 +63,7 @@
unsigned int truncate_header:1;
};
-static const char *solr_escape_chars = "+-&|!(){}[]^\"~*?:\\/ ";
+static const char *solr_escape_chars = "+-&|!(){}[]^\"~:\\/ ";
static bool is_valid_xml_char(unichar_t chr)
{