Если это Transact sql — то, интересует DB2 и PostgreSQL. По DB2 есть ли разница, под Linux он или z/OS?
Если это Nosql — то либо ElasticSearch, либо Ceph.
Вместе с продуктами интересует МАХ возможная нагрузка в кол-ве событий в сек. Интересует диапазон от 10 000 и более.
Еще вопрос:
В каком инструменте реализованы триггеры (при выходе метрики за допустимый диапазон, автоматическое уведомление об этом Администратора либо автоматический запуск скрипта)? Не могли бы Вы дать ссылку на документацию, чтобы получше ознакомиться.
Какого же было мое удивление, когда выяснилось, что Ucoz.ru более не поддерживает загрузку файлов html, обрекая вас использовать его конструктор сайтов помимо воли.
Это так с одним исключением. Если сайт небольшой, использование статичный html сайтов возможно.
если программа застряла в процессе построения, можно попробовать просто начать либо совсем с нуля, но с иными начальными условиями, либо откатиться на большее число итераций.
Да — можно однозначно! Идей, как улучшить алгоритм очень много. Проблема в том, что на реализацию идей уходит много сил, а профита иногда не просто нет а он отрицательный (у меня были 2 идеи, которые не сработали).
По поводу «начать с нуля» — это все таки должно быть решение пользователя.
Каюсь — не все возможности алгоритма были реализованы в конечной программе. Например, для тестов, я запускал 10-20 генераций одного и того же кроссворда, с лимитом по времени или по количеству операций — чтобы наработать средние значения времени генерации.
По поводу «откатиться на большее число итераций» — боюсь, что это опять решение без четкой логики. Основная проблема — а куда именно откатываться? Уж лучше сначала начать.
Привожу несколько идей, которые не были реализованы в алгоритме.
Одна из идей относится к формированию фрагментов. Я писал выше о дилеме в том, когда именно формировать фрагменты. Иногда, когда не удается сформировать фрагмент — приходится откатываться очень далеко. Возможно более оптимальным решением является не откат, а осторожный подбор других вариантов слов, с которыми пересекается этот фрагмент и повторное формирование фрагмента.
Еще одна идея — поиск в сетке неких точек минимальной сложности и выстраивание порядка генерации слов таким образом, чтобы конец генерации попадал именно на эти точки
И еще одна — я писал о балансировки сложностью установки, когда выполняется обрезка до 30% букв. Сейчас эта балансировка может меняться для самых длинных слов кроссворда. Возможно, ее нужно менять и для слов, которые никак не удается установить, либо вообще для всех слов динамически повышать и понижать в процессе генерации.
Интересная идея. А вот реализация, наверно нетривиальная получится.
У меня по всему алгоритму, наверно, всего 2-3 места с нечеткой логикой, которые определяются весовыми коэффициентами — и то я искать наиболее оптимальные значения намучился — а тут все на этом завязано будет!
Вот же, не знал, что составление кроссворда является сложной проблемой. Когда работал в газете — написал программу для составления готовых кроссвордов.
Самой большой проблемой было составление базы слов и вопросов. После пробного пользования — составили огромную базу слов, а по фактически заполненной сетке уже писали вопросы всех редакцией :)
Кому интересно — объясняю принцип построения.
1) Каждая клетка кроссворда анализировалась на предмет, является ли она первой, второй,… последней.
2) Определялись самые длинные слова в кроссворде и заполнялись первыми словами с учетом той информации, которая получена на шаге № 1 (например, нельзя ставить слово, у которого мягкий знак попадает на клетку, помеченную признаком «Первая» — то есть какое-то другое слово начинается с этой клетки).
3) Методом перебора к первым самым длинным словам прикреплялись подходящие все более короткие слова, но не менее 4 знаков. При этом каждая цепочка запоминалась и если для более короткого слова варианты заканчивались, предыдущее слово в цепочке менялось попытка подобрать более короткое слово повторялось.
К этому моменту кроссворд уже на 80% заполнен, в нем нет только слов на 3 и 4 буквы.
4) Подбирались короткие слова для пустых мест. Таких слов в базе было больше всего и обычно это не составляло труда (опять следует иметь ввиду, что все слова, поставленные ранее, ставились не на обум, а по правилам, т.е. не было такой экзотики, как двойные или тройные одинаковые буквы по соседству… ).
Некоторые замечания:
Надо сказать, что мои сетки были попроще, чем вариант выше.
Успешными были более 90% попыток, при этом этот процент рос по мере добавления правил, какую букву куда нельзя, а какое сочетание букв можно.
Время формирования — от минуты до часов. Обычно если время переваливало за час, делался стоп и все запускалось по новой.
Еще одним важным элементом геймплая была возможность давить пехоту. Танк, который умирал 1 против 4 в перестрелке, спокойно давил всех 4-х, если им правильно поездить…
Основную проблему представляют разбитые на отрывки (они же «run», представлены нодами <w:r/>) параграфы, содержимое Тэгов разбивается на несколько нод и в таком виде их обработать не получится.
и все-таки вариант есть :) — через RTF формат. Сам делал шаблонизатор через WORD. Вот пример шаблона для вывода 2-х таблиц:
Если интересно — пишите, с удовольствием поделюсь идеей…
Если это Nosql — то либо ElasticSearch, либо Ceph.
Вместе с продуктами интересует МАХ возможная нагрузка в кол-ве событий в сек. Интересует диапазон от 10 000 и более.
Еще вопрос:
В каком инструменте реализованы триггеры (при выходе метрики за допустимый диапазон, автоматическое уведомление об этом Администратора либо автоматический запуск скрипта)? Не могли бы Вы дать ссылку на документацию, чтобы получше ознакомиться.
Подтверждение — недавно делал статический сайт для статьи на Хабре.
Из танцев с бубном — первую страницу необходимо загнать в шаблон, по сути копи-паст html страницы + добавление Ucoz копирайта.
Это так с одним исключением. Если сайт небольшой, использование статичный html сайтов возможно.
На этом сайте Вы можете скачать программу и попробовать самостоятельно сгенерировать кроссворды.
Да — можно однозначно! Идей, как улучшить алгоритм очень много. Проблема в том, что на реализацию идей уходит много сил, а профита иногда не просто нет а он отрицательный (у меня были 2 идеи, которые не сработали).
По поводу «начать с нуля» — это все таки должно быть решение пользователя.
Каюсь — не все возможности алгоритма были реализованы в конечной программе. Например, для тестов, я запускал 10-20 генераций одного и того же кроссворда, с лимитом по времени или по количеству операций — чтобы наработать средние значения времени генерации.
По поводу «откатиться на большее число итераций» — боюсь, что это опять решение без четкой логики. Основная проблема — а куда именно откатываться? Уж лучше сначала начать.
Привожу несколько идей, которые не были реализованы в алгоритме.
Одна из идей относится к формированию фрагментов. Я писал выше о дилеме в том, когда именно формировать фрагменты. Иногда, когда не удается сформировать фрагмент — приходится откатываться очень далеко. Возможно более оптимальным решением является не откат, а осторожный подбор других вариантов слов, с которыми пересекается этот фрагмент и повторное формирование фрагмента.
Еще одна идея — поиск в сетке неких точек минимальной сложности и выстраивание порядка генерации слов таким образом, чтобы конец генерации попадал именно на эти точки
И еще одна — я писал о балансировки сложностью установки, когда выполняется обрезка до 30% букв. Сейчас эта балансировка может меняться для самых длинных слов кроссворда. Возможно, ее нужно менять и для слов, которые никак не удается установить, либо вообще для всех слов динамически повышать и понижать в процессе генерации.
Чем больше вариантов, тем меньше шанс подобрать слово на пересечении.
У меня по всему алгоритму, наверно, всего 2-3 места с нечеткой логикой, которые определяются весовыми коэффициентами — и то я искать наиболее оптимальные значения намучился — а тут все на этом завязано будет!
По факту напишу статью…
www.google.ru/trends/explore#q=%2Fm%2F0120vr%2C%20%2Fm%2F01vw9z%2C%20%2Fm%2F05ynw%2C%20%2Fm%2F04y3k&cmpt=q&tz=
Самой большой проблемой было составление базы слов и вопросов. После пробного пользования — составили огромную базу слов, а по фактически заполненной сетке уже писали вопросы всех редакцией :)
Кому интересно — объясняю принцип построения.
1) Каждая клетка кроссворда анализировалась на предмет, является ли она первой, второй,… последней.
2) Определялись самые длинные слова в кроссворде и заполнялись первыми словами с учетом той информации, которая получена на шаге № 1 (например, нельзя ставить слово, у которого мягкий знак попадает на клетку, помеченную признаком «Первая» — то есть какое-то другое слово начинается с этой клетки).
3) Методом перебора к первым самым длинным словам прикреплялись подходящие все более короткие слова, но не менее 4 знаков. При этом каждая цепочка запоминалась и если для более короткого слова варианты заканчивались, предыдущее слово в цепочке менялось попытка подобрать более короткое слово повторялось.
К этому моменту кроссворд уже на 80% заполнен, в нем нет только слов на 3 и 4 буквы.
4) Подбирались короткие слова для пустых мест. Таких слов в базе было больше всего и обычно это не составляло труда (опять следует иметь ввиду, что все слова, поставленные ранее, ставились не на обум, а по правилам, т.е. не было такой экзотики, как двойные или тройные одинаковые буквы по соседству… ).
Некоторые замечания:
Надо сказать, что мои сетки были попроще, чем вариант выше.
Успешными были более 90% попыток, при этом этот процент рос по мере добавления правил, какую букву куда нельзя, а какое сочетание букв можно.
Время формирования — от минуты до часов. Обычно если время переваливало за час, делался стоп и все запускалось по новой.
Мечты: Вот бы найти сравнение этих продуктов по производительности в кластере, желательно еще и масштабировать кластер в 5 раз, в 10 и т.д.
и все-таки вариант есть :) — через RTF формат. Сам делал шаблонизатор через WORD. Вот пример шаблона для вывода 2-х таблиц:
Если интересно — пишите, с удовольствием поделюсь идеей…