First of all a bit of environment: I have a large part of database for search (well it counts in tens of millions of records) with need for
a) fast search (so there must be some indexes).
b) fast update with lots of data (again several millions of records of updates a day are usual).
c) some sort of uniqueness so that cache contains only latest record for some condition.

Actually insert/update/delete optimization is pretty simple: every index you have slows updates down, so don’t make too much of them. But there is another case to consider: how much pages of index would be updated in case of data update.

In my situation the goal c) was achieved by using md5(of some fields), this is quite a good key it has perfect distribution (there are no repeating numbers and also they are spred very well). It’s also quite usefull in operations: single field in index, single equality in join.

But there was one problem: when I tried to insert let’s say 100K rows with new equality keys it distributed almost to every page of an index, so operation was very sloowww. Thanks to good distribution of equality_key . Sadly situation get only worse over time as overall size grows, because updates are still very random.

Solution in my case was to «group» this index in a manner it is updated (in my case it is hotel_id, departure_date, and only then equality_key). This gives much better locality in updates and little impact in search perfomance (actually due to locality impcat should be even positive). I have some numbers but they wouldn’t say much and it’s not a purpose of this post. In my case update perfomance was boosted by an order of magnitude, and it should degrade so much with growth of DB size, so now I’m happy .

The overall rule to consider in optimizing inserts/updates/deletes is to look on how many index pages would be updated in typical update situation (i.e. index could be thought as table records sorted in index order (actually it’s a lot different, but still model is very nice in many situations)). Ideally only pages, related to new data should be updated almost fully, and other should not be touched.

This might be very very simple and obvious when you know about it. But some people (like me) don’t know this. I hope this would help.

Порывшись в исходниках нашёл способ, как оно работает (меня ещё со времён squeryl эта магия интересовала, но там так и не докопал сырцы)… там походу дела alias при помощи cglib генерирует класс-прокси (в отличии от JDK Proxy, которые только для интерфейсов, cglib позволяет генерить и класс-прокси). А вот что с ним дальше делать? А тут похоже всё просто – хранится «глобальный» (видимо для алиаса) путь, соответственно вызовы прокси этот путь увеличивают, например, c.getKittens() кладёт нужную запись в локальный путь, а $(…) тупо выдёргивает весь последний путь, немного контролируя типы и сбрасывает память пути. Вуаля, получаем обработку вызовов object.getSomething().getSomethingElse().getSomethingMore(), которая компилируется, а в рантайме генерирует путь.

Очень просто – ему даётся некоторый объект, он его хавает, заполняет по нему то, что должен сейчас редактировать, дальше ОК/Отмена, если ОК – проверяет, всё ли правильно введено и если всё верно – применяет редактирование к объекту. И тут всё просто и хорошо.

А вот что, если отмена? По идее ничего, просто не надо ничего применять. Объект остаётся в исходном состоянии.

И вот тут начинаются сложности, как бы так не изгадить исходный объект. Вариант первый, можно использовать своего рода «патчи» – т.е. редактор накапливает изменения и применяет их _всегда_ только, если все проверки пройдены.

Проблемы:
- Если какие-то проверки целостности завязаны на совокупное состояние объекта (скажем, что поле А меньше поля Б), то логику проверки придётся продублировать в диалоге. Нельзя использовать зашитое в объекте, т.к. нельзя в него записать (вдруг проверка не пройдёт и будет «отмена»).

- И это бы ладно, но что делать, если редактор в том числе вносит изменения в списковое поле?

Пример:
Редактируем партнёра
+ гридик с его юр-лицами.

Соответственно в процессе редактирования партнёра юр. лица могут добавляться, удаляться, изменяться. При изменении юр. лица показывается редактор юр. лица (так или иначе) и он вообще говоря знать не знает про то, что он показан в контексте редактирования партнёра и ему надо накопить изменения, но не применять (т.к. редактирование партнёра может и отмениться).

В общем на списках у меня эта стратегия работы с накоплением изменений и загнулась.

Альтернативно сейчас думаю над вариантом, когда редактор начиная что-то править делает себе полную копию того, что ему дали (а это ой как не просто, сделать полную копию ), и делает с ней что хочет, если всё успешно – возвращает и это уже обязанность вызвавшего правильно «пристроить» эту копию – записать себе в список, сохранить в БД или ещё чего с ней сотворить.

Отдельно есть сложность составления копии… тут уже весёлости Java. В общем, с clone всё очень непросто, там и жёсткие проверки не сделаешь и с теми же коллекциями хлопот много.

В общем из способов не слишком обременительных пока нарыл Serializable + засериализовать/рассериализовать… криво, сначала даже думать не хотел в эту сторону, но всё остальное ещё хуже.

В общем это так, поток мысли в процессе. Кто что скажет?

Простой запрос:

Запрос простой, тут нестыковка очевидна – несмотря на то, что хочу я получить все заказы, с активными менеджерами, либо заказы без менеджера (т.к. LEFT JOIN), получу я только лишь заказы с активными менеджерами. Проблема в том, что там где менеджер не найдётся (предположим это необязательное поле), m.is_active будет NULL, а когда я сравню NULL c true, я получу ложь. И такие записи меня не устроят.

Решение? Обходное – m.is_active is null or m.is_active = true. Правильное? Вероятно здесь надо просто перенести условие в условие JOIN-а (на самом деле в зависимости от того, что я имел ввиду).

Самое простое в программе – локальные переменные. Почему? Они живут на стэке => существует один экземпляр для одного вызова функции. Вся работа с ними у нас перед глазами – все изменения и чтения => мы можем легко добавлять новые, менять и убирать старые. Всё у нас в руках. Есть полная уверенность, что ни одна другая часть программы не может влиять на них.

Второе – параметры функции и возвращаемое значение. Также простая штука. Они у нас перед глазами. Они также живут на стэке, т.е. в рамках одного вызова мы можем быть уверены, что они полностью в нашей власти (никто снаружи не залезет и не изменит их). Единственная проблема с ними – могут дать не то, что надо, но и от этого можно обезопаситься: заставить компилятор проверить правильность типа, да и самим проверить значения/тип на допустимость, и после этого работать с ними спокойно.

Прелесть локальных переменных и параметров в том, что работая с ними надо держать в голове только лишь один метод, про всё остальное можно забыть. Нам что-то дали и мы должны что-то вернуть, это описано в начале и больше нас ничего не волнует.

Поля экземпляра. Тут уже всё несколько сложнее. Проблем несколько:

1. Чтобы понять, какие поля использует метод надо прочитать его. Т.е. нигде в его заголовке это не описано.
2. Доступ к полям имеют все методы, а значит они могут их менять. Это означает, что на протяжении работы нашего метода, если он не дай бог вызывает что-то ещё, значение поля может измениться.
3. Значение поля одно на один экземпляр, а значит при рекурсии могут быть проблемы.

Таким образом, при работе с неконстантными полями объекта в голове надо держать уже весь класс целиком (все методы, работающие с полем), всех предков (если поле унаследовано) и всех потомков (если поле не private). А это довольно сильно повышает нагрузку на мозг. Не всё так страшно, если использовать несколько правил:

• Не надо использовать поля объекта для передачи параметров в фукции, для этого есть… параметры функций.
• Тоже самое с результатом работы метода (за исключением редких случаев).
• Поля объекта удобно использовать для настройки объекта, которая задаётся в конструкторе и не меняется на протяжении всей жизни объекта (либо меняется в очень понятных точках).
• Поля лучше делать private, от греха подальше (область которую надо держать в голове сразу сокращается до одного класса), аналогигчно, public заставляет помнить про всех пользователей класса.

Глобальные переменные. Тут вообще в голове надо держать всё глобально – всё, что может писать в переменную. Да ещё и экземпляр всего один. Реально они нужны довольно редко. Кстати, на заметку, Singleton == глобальная переменная (почти). И тоже нужен крайне редко (инъекция зависимостей – наше всё).

Маленькое итого. Надо стараться по максимуму использовать передачу данных функциям. Параметры – значит параметры функций, результат – значит результат. Параметры должны быть явными (по максимуму типизированными) и понятными, что не понятно компилятору/парсеру должно проверяться на входе. После этого можно выбросить из головы происхождение параметров и писать только логику функции.

Поля объекта – для настройки объекта (вообще говоря, для состояния объекта, но состояние должно поминимуму включать временные переменные). И private, чтобы меньше заботиться.

• Я не могу держать в голове более 7 +/- 2 вещей.
• У меня хорошая память, но я не могу запомнить все переменные, выражения, методы и классы в программе.
• Также я не могу помнить все зависимости в коде.
• Я плохо читаю запутанный код (и не хочу этого делать).

Т.е. я на самом деле слышал, что существует лишь одно существо, неподвластное этим ограничениям… правда его зовут по разному, и с доказательствами туго. Но тем не менее, это не означает, что мы не можем писать большие хорошие работающие программы.

Нужно всего то:

• Сократить объём вещей в памяти до необходимого количества ( = сделать остальное ненужным для решения конкретной задачи).
• Использовать средства, готовые в любой момент заменить мою дырявую память (IDE), использовать максимальное количество проверок (компилятор, тесты), а также делать названия настолько очевидными, чтобы я не помнил название, а правильно его составлял каждый раз.
• Максимально упрощать зависимости = делать их очень явными и локальными.

Собственно на решение этих задач направлено всё искусство программирования, все методы, будь то выделение процедур из алгоритмов, выделение объектов из сложного взаимодействия или преобразование алгоритма в более декларативный, более понятный вид.

Что интересно, для того чтобы программировать быстро и качественно необходимо всего лишь победить эти проблемы, т.е. программировать понятно, а это даст всё остальное.

Заметка первая, зачем всё это нужно.

Мы никогда ничего не пишем только чтобы написать. Пишем мы, чтобы оно работало, развивалось, цвело и пахло. Ещё нельзя исключать такую вещь, как итеративность. Как бы нам ни хотелось, реалии таковы, что задачи не ставятся целиком, что сделали и всё. Нет, мы делаем макет, потом делаем пробную версию, потом делаем рабочую версию, потом делаем рабочую рабочую версию… ну вы поняли, и так раз 5, 10, 20, 100, в зависимости от длины жизни проекта (что самое забавное – чем живучее проект, тем больше раз мы будем в нём что-то менять/дорабатывать).

Ах да, ещё есть такая проблема, что всё надо делать а) быстро и б) хорошо. Казалось бы несовместимо. Совместимо. Причём иногда оказывается, что быстро и плохо сделать не получается. Парадокс.

Я отвлёкся. Суть такая, что основная задача – быстро писать качественный код, при чём такой, который потом можно будет также быстро дорабатывать, менять, убирать и т.п. Важно – чтобы потом можно было не выкинуть всё и начать заново, а именно использовать максимум наработок.

Собственно об этом всё дальше и будет.

Итак, что было

Нас учили, что основные понятия ООП, это:

• Инкапсуляция
• Наследование
• Полиморфизм

При этом инкапсуляция – сокрытие всего так, чтобы снаружи знали поменьше о классе; наследование – возможность создавать новые классы на базе существующих, заменять в них методы, дополнять, и использовать части предка; полиморфизм – возможность использовать один класс вместо другого (как правило из той же иерархии)… ну в общем тут был совершенно замечательный пример про рисование – фигура – линия, фигура – квадрат.

То, что я извлёк (это вероятно относится и ко мне и к программе, т.к. очень многие после той же программы думают также) – это то, что я могу написать в резюме «я знаю ООП», что в итоге сводится к тому, что я умею записывать процедурный код в классы, и моим любимыми паттернами являются недоделанный Template Method и God Object (не в крайнем проявлении, но как направление).

Что надо было вбить или услышать

Инкапсуляция - это не только то, что можно сокрыть часть данных и методов, но сам принцип, что мы ограничиваем внешнее знание об объекте с целью уменьшения количества зависимостей. А также важны примеры, как это делать или не делать… без фанатизма «все свойства должны быть закрытыми», но с пониманием того, что надо задумываться «а по сути это ожидается снаружи?».

Простите крамольную мысль необразованного человека, но интерфейсы – тоже форма инкапсуляции, потому что оставяют от всего интерфейса класса только несколько согласованных методов, уменьшая зависимости.

Наследование - о да! Наследование решает все проблемы . И на следующем шаге порождает в два раза больше, если использовать неправильно. Особенно прикольны рассуждения «этот метод нужен в 3 из 5 наследников, давайте поднимем его в родителя». Вообще наверное корень зла в том, что наследование у меня в своё время спозиционировалось, как способ повторного использования кода, хотя таковым не является. Наследования – это отношение «является» и очень сильная связь между двумя классами. Если нужно повторное использование кода – есть масса других механизмов.

Мой любимый Template Method хотя и имеет право на жизнь в принципе, но в тех объёмах, в которых он использовался (и используется порой :-Р) – страшное зло, потому что исполнение неявно скачет из одного класса в другой и когда что произойдёт предсказать сложно (как и что обрушится, если что-то изменить). (З.Ы. Там надо было его ограничивать и делать более строгим, никаких реализаций по умолчанию, которые потом опционально перекрываются).

Ещё про наследование – очень важная вещь – принцип подстановки Лискоу. Что объект порождённого класса должен использоваться везде где используется его предок без нарушения интерфейса (в частном) и вообще обещаний (в целом). Является ли правильной цепочка наследования Фигура – Прямоугольник – Квадрат? В общем нет, потому что с точки зрения программирования Квадрат часто не является Прямоугольником (как «честно» реализовать методы setWidth/setHeight в квадрате?).

Полиморфизм – вот тут интересно, пусть это моё имхо, но полиморфизм надо рассказывать на базе интерфейсов (каждый класс – неявно порождает интерфейс, который наследуют предки, так что для классов и наследников всё верно).  И это тоже к принципу подстановки Лискоу – кто реализует интерфейс – реализует его полностью и соблюдая обещания, если нельзя полностью – то что-то не так, возможно нужно два интерфейса вместо одного.

А сюда кстати завязана инкапсуляция с другого конца – каждый код должен очень чётко и минимально сформулировать, что ему надо от других объектов, и больше ничего не спрашивать. Именно поэтому я считаю, что интерфейс должен предоставляться «потребителем» объекта. Т.е. если есть алгоритм сортировки, то он даёт интерфейс «Сортируемое» – и уже задача пользователя реализовать его или адаптер, если они хотят сортироваться этим алгоримом. Можно пойти и дальше, отвязав для нескольких потребителей общий интерфейс, важно, не столкнуться с ситуацией, когда интерфейс распухает, а каждый потребитель использует только часть – тогда нужны разные интерфейсы. // Лирическое отступление

Вообще. Наверное одна из причин была в том, что на ОО программирование смотрелось со статической позиции – как распихать код по классам, и не было никакого понимания, что классы должны взаимодействовать и основная собака здесь – это должно быть понятно, гибко и эффективно.

З.Ы. повторное использование. Написал выше, что без наследования, а как иначе? Мы создали объект, вызвали метод – вот мы и использовали код повторно. Надо поменять? Сделаем, чтобы метод (или конструктор объекта, это зависит от ситуации) принимал другой объект, реализующий меняющуюся часть – вот у нас появился «набор» методов – для каждого нового объекта это новый метод (это и есть полиморфизм). Код использовался повторно, а мы не обременили себя жёсткой связью «наследуется», код гибкий.

Что ещё

А ещё очень интересно расширить применение и показать альтернативы. Расширить применение – показать, что такое TDD, объяснить, зачем и дать попробовать… ещё при обучении. Это классная лакмусовая бумажка, показывающая закрепощённость и неправильность ОО-кода.

Альтернативы – мне очень понравилось познакомиться с миром функционального программирования, не могу сказать, что я по нему спец, но это однозначно добавило новых подходов в моё программирование. Об этом тоже надо рассказать.

Функциональное программирование – всё функция. В применении к вебу страница – это функция от GET, POST, FILES, COOKIES. Функция не имеет состояния – т.е. результат всегда зависит только от параметров, и это один из полезных принципов. Функция может быть суперпозицией других функций, функции могут передаваться как параметры, может быть замыкание – функция, принимающая в качестве параметров часть того места, где она быа создана (не знаю, правильно ли это теоретически, там carrying и всё такое, но по сути так).

Что это даёт в моём ООП? То, что в объектах не должно быть состояния помимо их настройки, да, настройка может меняться, но при этом вся динамика – отдельно. Пример. Есть класс, обрабатывающий ввод данных, должен ли этот класс сам хранить введённые данные и ошибки ввода? Нет, они не имеют к нему отношение – они являются результатом проверки. Он хранит настройку «как проверять», её можно менять по ходу, но он не хранит сами результаты, желательно даже во время обработки.

Ещё одна штука – связь вызовов методов. Имхо желательно минимизировать зависимости «вызови метод А, получи результат, добавь и вызови метод Б», и не дай бог метод А что-то меняет внутри объекта и без него метод Б вызвать нельзя это совсем ужас… Да и вообще, начинал писать абзац к тому, что очень многие вещи решаются паттерном «Команда», что является ничем иным, как замыканием в функциональном программировании – это объект, который можно настроить при создании, а дальше у него есть только один метод с определёнными параметрами… такой аналог функции-параметра.

Итого – сейчас очень тянет к архитектуре, где объекты хранят только то, что определяет их работу, но не промежуточные данные, сами объекты маленькие, фактически близки к функции с несколькими предзаданными параметрами… возможно к семейству функций с одинаковыми настройками. А результат работы программы – некий прогон входных данных через сеть связанных объектов. Сама сеть от этого меняется только если входные данные заставляют её измениться, все же временные эффекты после выполнения забываются. И этот подход транслируется на каждый отдельный кусочек выполнения.

С погодой повезло не особенно – первую часть путешествия был мелкий дождик (а стоянка в районе агнарского перевала так и вообще проходила в облаке – тот же мелкий дождь + сильный туман). Потом всё более-менее раздуло и облачка чередовались с чистым небом.

Вообще по походу можно многое написать, это мой первый поход и впечатлений масса, из целей – мы почти забрались на Чатыр-Даг (как позже выяснилось забрались мы на более низкую вершину, Ангар-Бурун), на Южный Демерджи у меня в этом году забраться не вышло – пришлось остаться в лагере. Так что есть для чего возвращаться.

Вторая часть отдыха проходила в Коктебели… тут можно много рассказать – отличная еда – солёности, местная (мясная!) колбаса, вкуснейшие кисломолочные продукты (такой сметаны я ещё не ел)… и конечно же вина. Дегустация в Солнечной Долине, портвейн 90-го года, и куча куча всего другого. Жаль, в моём городе нет фирменного магазина, с ним жизнь была бы веселее ).

Вот. В общем пора работать, а рассказывать можно очень долго.

З.Ы. едва не забыл самое важное! Самое классное в этом походе – это компания, «старейшие» члены которой ходят в эти места едва ли не 20 лет. Именно компания сделала интересный поход по интересным местам действительно офигенным и незабываемым.

На самом деле, я наверное больше хочу сделать акцент на теории, нежели чем на практике, дать несколько советов, а по практике – опыт ничто не заменит.

Что такое отладка?

Начинается всё с поиска ошибки. И здесь мы должны пройти путь от «ничего не работает» к тому, что ошибочной является одна строка и то, зачастую, ошибочна она только при определённых внешних условиях. В принципе весь процесс поиска ошибки заключается в сужении контекста ошибки.

Как сужать контекст ошибки? В целом это всегда уменьшение размера кода, в котором потенциально находится ошибка, а также условий, значений ввода и т.п. Т.е. пришёл менеджер «ничего не работает» – контекст – весь код. Что не работает? Такая-то страница. Что там? Форма не сохраняется. А что вводили? …

Эта часть очевидна, я просто хочу подчеркнуть, что это всего навсего сужение контекста ошибки. Дальше процесс точно такой же – формулируем некоторую гипотезу «на входе в скрипт данные правильны» – смотрим данные $_POST, ага, всё, про ошибки в хтмл можно забыть, это не там. Или наоброт. Т.е. дальше процесс идёт также, последовательным уменьшением контекста ошибки, пока она не станет ясна.

Что может помочь?

Сначала вопрос, а как мы определяем верность того или иного утверждения? Мы смотрим на какие-то значения в разных участках программы. Соответственно чем эффективнее мы будем смотреть, тем быстрее сможем искать.

• Расстановка var_dump-ов будет очень неэффективной (хотя приемлимой для начала). 
• Могут помочь различные встроенные трассировки (например, у нас есть режимы, когда по параметру в адресе хорошим людям выводятся все SQL запросы, все удалённые ошибки и т.п.). Это позволяет проконтролировать несколько точек сразу, даже не касаясь кода.
• Не забываем про firebug – это очень хорошее средство контроля вывода, ввода (можно смотреть что постилось, какие куки, какие заголовки) и взаимодействия – вкладка «net». 
• Наконец, последнее по порядку не по значению, интерактивная отладка на сервере (пусть даже локальном). Интерактивным отладчиком однозначно стоит овладеть, он позволяет смотреть все переменные, проходить о всем вызовам и т.д., т.е. если сравнивать с вардампом – это возможность посмотреть вардамп любой желаемой переменной на любой строке без перезагрузки страницы и правки кода. Это очень быстрое средство при отладке средних и сложных ошибок.

А ещё?

• Ещё надо поменьше доверять и побольше проверять. Я не раз попадал на часовую отладку ошибки в рабочем коде просто потому, что подумал «я знаю, ошибки в этом месте нет, надо смотреть там» – подумал и не проверил, на самом ли деле нет ошибки. Просто надо держать глаза открытыми.
• А ещё при отладке, как это ни странно, помогает грамотно написанный код. Как заметил один мой умный знакомый, нет режима «убирания ошибок», есть режим «скрытия ошибок», но они никуда не уходят. Т.е. приложение должно быть написано так, чтобы максимально сообщать о том, что что-то пошло не так, сразу же, как пошло не так. Очень хороший материал – МакКоннелл, «Совершенный код», глава про защитное программирование.

Ошибку нашли, что дальше?

Дальше её надо исправлять. Здесь тоже пара моментов:

• Если ошибка сложная, очень желательно её не заткнуть, а понять суть проблемы (для сложных ошибок обычно надо искать проблему в понимании логики приложения/предметной области). Такое исправление будет более сложным, зато снимет проблемы в будущем.
• Модульные, браузерные и прочие тесты. Если они есть – исправлять сложные ошибки, переписывать большие куски и т.п. – удовольствие – код становится лучше и ты знаешь, что можешь проверить, чтобы ничего не сломать.
• Подобные ошибки. Исправив одну ошибку, часто даже уже коммитя её, я задаю себе вопрос «а где может быть такая же ошибка?»… и исправляю ещё пару мест, которые вылезли бы с такими же страданиями через неделю-две.

Учимся или стоим на месте?

Если мы хотим не просто исправить ошибку, а чему-то научиться: надо подумать, как не совершать таких ошибок в будущем. Т.е. как писать код, который бы или исключал подобные ошибки, или делал их менее вероятными, или просто лучше предупреждал бы о них. Это сложный процесс – от исправления сообщений об ошибках на более внятные до изменения стиля программирования. Но это один из способов развития программиста, и далеко не самый последний.