Hello1: проблема в формулировке. Накопитель должен читать-писать свой номинальный адресуемый диапазон LBA. Если этого не происходит либо происходит с ошибками - да, это гарантия. Если же всю свою адресуемую ёмкость диск читает и пишет - значит диск исправен. И никого не волнует, что это достигнуто резервной областью диска и ремапами неисправных секторов в эту область. Если просто в каком-то там SMART значение какого-то там параметра не 0 - это не является дефектом.
> Это может быть как S-ATA1 (в таком случае покупка SSD выглядит неоправданной тратой денег)
Оправданной.
Да, в этом случае не нужен топовый диск. На десктопах всё-таки не такие жёсткие требования к случайному вводу-выводу, где даже современные топовые SSD едва преодолели отметку в 50мб/с (случайное чтение, глубина очереди 1).
IOPS же штука полезная только с указанием методики тестирования. И не имеет ровно никакого отношения к времени доступа. Можно и на одном SATA HDD намерить 300-400 IOPS из физически возможной сотни. https://habrahabr.ru/post/154235/
На указанные производителем цифры можно вообще не смотреть. Там всё равно будут пиковые цифры с идеальных условий, если вообще реальные, а не с потолка переписали.
Передача данных на стороннюю машину - зачем вообще делать синхронно? Кладёте сообщение в очередь. Демон, который очередь разгребает, на 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
Нужно ли делать М:М или достаточно денормализованной предыдущей реализации вопрос отдельный. Конкретно для ключевых фраз я не считаю нужным их нормализовать полностью, много лишних действий, а профит довольно неочевидный.
Нормальная форма реляционной БД - давний технический термин. Объясняется много где и много как. На первый взгляд указанная статья об этом, только как-то очень коротко.
