Передача данных на стороннюю машину - зачем вообще делать синхронно? Кладёте сообщение в очередь. Демон, который очередь разгребает, на dev вообще не запускаете (кстати, очень простой и дубовый демон, который становится куда легче отлаживать, т.к. выполняет только 1 задачу). Можете подцепиться к очереди и посмотреть, всё ли правильно оформлено для отсылки на сторонний сервис. Не говоря о штатной работе, если удалённая машина недоступна - демон разгребёт очередь попозже.
И это же хороший пример конфигов, которые на dev-машине вовсе неуместны. По крайней мере во включенном состоянии. Даже в синхронном режиме работы запросы просто заворачиваете на эту же локальную машину с простой и глупой эмуляцией API и ведением логов для разбора, правильный ли запрос был отправлен.
Хотите закомментировать временно - зачем вообще в гит коммитить? И зачем хотите комментировать? Может, это должна быть директива конфига на самом деле, отключенная в dev-окружении?
Конфиги вы должны иметь возможность создавать разные. Реализовать можно разными путями - через переменные окружения сообщать, конфиги какого окружения подтаскивать; класть в гит глобальный дефолтный конфиг, а в прописать .gitignore локальный конфиг, который собой может заменять некоторые директивы из глобального и всякие другие способы. В частности, продовых конфигов в гите может не быть вовсе.
dev и prod на разных платформах - вообще порочная практика. Используйте vagrant с окружением, наиболее близким к проду. Ну кроме случая, когда вы пилите что-то коробочное, что должно работать на любых чайниках.
Ну ладно. Значит берёте исходник и раскуриваете его. https://github.com/zendframework/zf1/blob/master/l... ничего примечательного, что-то неверное генерируется для _execute. Метод public, так что берите стектрейс и читайте промежуточный код, где поведение идёт куда-то не туда.
> непонятно отличие переменной заданной через SET и переданной в процедуру с точки зрения возможности её изменения
Я видимо спутал с каким-то другим диалектом, думал, что IN параметру в принципе ничего другого присвоить уже нельзя. Оказывается, можно.
Но переменные - всё-таки другая штука. Во время выполнения запроса переменную изменить легко, а вот параметр - уже нет, с ходу вообще не получилось найти способа. У них даже разный синтаксис.
По поводу индекса по dt - чтобы получить данные по индексу, надо прочитать индекс, доставать из него указатели на данные (а в случае Innodb это значения первичного ключа), потом доставать данные. Это всё дофига случайного чтения.
Если относительно общего массива данных вам нужно получить небольшое число строк - то по индексу работать всё-таки гораздо быстрее.
А вот если по индексу выбирается много данных относительно общего массива - часто выгоднее от использования индекса отказаться и читать напрямую таблицу простым и последовательным чтением seq scan. Некоторые данные прочитаем напрасно, но последовательное чтение на пару порядков быстрее случайного.
Судя по названию таблиц, у вас большая часть данных будет как раз в куске индекса до указанной даты.
Возвращаясь к теме - да, всего на 50 тыс записей виснуть не должен.
Посмотрите как mysql переписывает запрос: после explain сделайте show warnings - будет примерный вид переписанного оптимизатором запроса. Может будет понятнее, что он решает делать странно.
entermix: честно говоря, для mysql - не знаю.
Есть вот такая информация: "The InnoDB engine is fully ACID compliant, but fails the standard definition of consistency when using a combination of InnoDB, foreign keys with cascading actions and triggers. This is the result of triggers being implemented at MySQL's SQL layer and foreign keys being implemented at the InnoDB Storage Engine level. " https://www.wikivs.com/wiki/MySQL_vs_PostgreSQL#AC...
И где-то ещё на профильных конференциях слышал, что триггеры у mysql не всегда ACID. Но подробнее не копал.
Схемы позволяют разбить базу на набор взаимосвязанных кусков.
Из программирования довольно близкий аналог - пространства имён.
Например, вы не плодите таблички billing_transactions, billing_operations, billing_operation_types, а создаёте схему billing и в ней таблички transactions, operations, operation_types. Тьма табличек с префиксом элегантно разбивается по схемам.
Затем, на схему можно дать отдельные права доступа. Например, что пользователь под которым ходит веб-морда не может ничего удалять или обновлять в схеме биллинга. Но, разумеется, должен иметь права обновлять свой профиль и т.п.
Это больше похоже на попытку сделать текстовый поиск.
Нет, это не то, о чём написан исходный ваш вопрос.
Исходный пример:
id1: Пальма, яма, Алексей, котики, погода.
id2: С++, яма, море.
В одном поле понаписано несколько элементов данных - так это работать не будет.
Ключевые слова выкидываются в отдельную таблицу и разносятся как связь 1:М. Получается таблица из двух полей:
id1: Пальма
id1: яма
id1: Алексей
id1: котики
id1: погода
id2: С++
id2: яма
id2: море
Вот так уже можно легко и быстро искать по этим ключевым словам.
При том, и для id1 и для id2 есть слово "яма". Значит, схема ещё не в нормальной форме, есть дублирование данных. С точки зрения реляционной теории нужно сделать отдельную таблицу ключевых слов:
1 - котики
2 - яма
И отдельно таблицу для реализации связи М:М
id1 - 1
id1 - 2
id2 - 2
Нужно ли делать М:М или достаточно денормализованной предыдущей реализации вопрос отдельный. Конкретно для ключевых фраз я не считаю нужным их нормализовать полностью, много лишних действий, а профит довольно неочевидный.
Нормальная форма реляционной БД - давний технический термин. Объясняется много где и много как. На первый взгляд указанная статья об этом, только как-то очень коротко.
1) поэтому возможность отказаться от фильтра по ip.
2) ну а по домену вы в принципе не ограничите. Нет такого поля в L3. Только в варианте с callback'ом, который весьма сложнее для реализации клиента.
L2, L3 - уровни OSI
Нет, скайпа нет. Что там в виндах - понятий не имею, не пользуюсь.
Дальше колупать в... За давностью лет даже не помню, как такое у гугла спрашивать. Попробуйте погуглить simple linux router, linux home gateway
В общем нужны /proc/sys/net/ipv4/ip_forward и iptables с MASQUERADE
> инет есть на той машине где мост создан, а на той машине куда он должен раздаваться по eth1 - нету
> прямое подключение, привязанное к маку сетевой
Видимо, ваш провайдер отфильтровывает пакеты с MAC-адреса машины, подключенной физически через eth1.
На всякий случай: вы L2 от L3 отличаете? Мост и роутер не путаете?
Ваши комментарии позволяют предположить, что вы хотите сделать роутер, но зачем-то полезли делать мост.
Что-то вроде этого.
Можно порезать на json документы и пихать их в какой-нибудь mongodb или ещё что-нибудь документо-ориентированное. Или в jsonb postgresql.
Можно нормализовать в реляционную базу. Получится более строгая схема.
Не знаком с вашей предметной областью, но разве в суде судья всегда только 1? Коллегиальные суды не рассматриваете?
Да, придётся парсить эти данные по всему массиву документов. Перебрать лям документов раз в год по требованию - это принципиально не то же самое, что перебирать лям документов в рантайме.
Это самая малая из предстоящий проблем, чистое машинное время, да и то не слишком большое. Миллион документов не так и много. Хотя, конечно, в зависимости от документов и как вы их разбор реализуете.
По граблям "в этих документах 'Судья на заседании', в тех - 'Судья'" или "здесь Иванова А.А., там А.А. Иванова, а сям - полностью ФИО" и ещё каких-нибудь вариациях пока не ходили, что ли? Якобы типовые документы нормализовать до на самом деле стандартной формы бывает не просто. А то ещё выходит распоряжение, и до такой-то даты по одной форме пишется, потом по другой, потом по третей. Тут имея вагон времени разобрать трудоёмко, а вы в рантайме хотите.
И это же хороший пример конфигов, которые на dev-машине вовсе неуместны. По крайней мере во включенном состоянии. Даже в синхронном режиме работы запросы просто заворачиваете на эту же локальную машину с простой и глупой эмуляцией API и ведением логов для разбора, правильный ли запрос был отправлен.