Ответы пользователя по тегу MySQL
  • Большое потребление виртуальной памяти MySQL на OpenVZ?

    @egorinsk
    VIRT это размер адресного пространства процесса (ну как-то так), а не потребляемая память. Реально выделенная память ближе к цифре, которая написана в RSS. Потому 350 мб вас не дложны беспокоить, но если вы хотите узнать причину, то надо делать pmap процессу mysql — он покажет, куда используется память.

    Кстати, куда вы прописывали ulimit? Я подозреваю, вы просто не туда ее вписали, если она не работает.

    Также, советую вам уходить с OpenVZ хостингов. Они учитывают не реальное потребление памяти, а этот самый VIRT (который гораздо больше), и хостеры за счет этого продают больше памяти, чем есть в сервере (насколько больше — зависит только от жадности хостера). А клиент, соответственно получает меньше, чем он бы получил от Xen или реальной машины аналогичной конфигурации. Вам придется постоянно мучаться с оптимизацией софта (так как многие программы выделяют адресное пространство, не считая его, оно же виртуальное) и придется разбираться с падениями программ из-за перерасхода памяти. Оно вам нужно?
    Ответ написан
  • Bug или Feature Autocomplete на сайте?

    @egorinsk
    > Так вот часто символы % и _ не заменяются и не экранируются, что приводит к следующему:

    Это обычная невнимтельность разработчиков, эти символы надо экранировать и они будут работать как задумано.
    Ответ написан
    Комментировать
  • Какие почитать статьи по повышению производительности баз данных?

    @egorinsk
    EXPLAIN пользоваться умеете? Мониторинг и запись в лог медленных запросов настроили? Памяти достаточно выделили?

    Советую также, если не читали, почитать для начала офиуиальный мануал в той части, где рассказывается про настройки и потребление памяти.
    Ответ написан
    Комментировать
  • Sсhemaless для MYSQL, как?

    @egorinsk
    Это будет быдлокод. В лучших традициях жителей теплой Индии. А добавление поля в большую таблицу вообще может занять часы, так что ваш скрипт бодро отвалится по таймауту. Но даже если бы оно делалось мгновенно, это был бы быдлокод.

    Хотите schemaless? Просто делаете одну таблицу entities с 3 полями: id, type, blob (в blob сваливаете JSON версию объекта). Но вообще, schemaless — крайне дурацкая идея. БД предлагает дополнительный уровень проверки и организации данных, а ленящиеся изучить язык SQL кажем так, юные программисты, кричат, что им этот SQL не нужен.

    Естественно, предложить нормальную альтернативу проверенным надежным решениями никто не может, а монго выглядит как примитивный Key Value storage с яваскриптом для игроделов (ибо эти товарищи даже SQL осилить не смогли). Все серьезные организации используют SQL.
    Ответ написан
    1 комментарий
  • Имеет ли смысл писать свою обертку над PDO?

    @egorinsk
    PDO из коробки малоюзабелен и неудобен: не считает время и статистику запросов, не поддерживает ленивого соедиения, пула соединений, транзакций, нормальных плейсхолдеров. потому обертку писать стоит в 90% случаев.

    А вот написать обертку, позволяющую прозрачно для кода менять СУБД, у вас не получится. В MySQL есть LIMIT, INSERT ON DUPLIATE KEY UPDATE и куча вещей, которых нет в других БД. Что вы с ними делать будете, чтобы заставить работать в оракле?
    Ответ написан
    1 комментарий
  • Файл, являющийся отражением дампа БД MySQL?

    @egorinsk
    Внимание, правильный ответ.

    Вместо скачивания файлов вручную и, тем более, написания своих файловых систем, необходимо написать скрипт (на любом нравящемся вам языке, я бы выбрал bash), который будет соединяться с сервером по ssh, делать дамп БД, и коммитить все нужные файлы в SVN. Сам будет делать всю работу, а не вручную. Тогда проблема «забыл закоммитить файл» исчезает автоматически.
    Ответ написан
    5 комментариев
  • Как правильно спроектировать БД MySQL?

    @egorinsk
    Слишком много таблиц
    Ответ написан
    Комментировать
  • Почему mySQL постоянно уходит в swap?

    @egorinsk
    Так а в чем ваша проблема? MySQL выделяет столько памяти, что ОС вынуждена часть его вытеснить в свап, или MySQL потребляет столько, сколько и должен, просто частично вываливается в свап? Во втором случае вам надо играть с параметрами ядра, отвечающими за swappiness и подобные вещи. В первом — смотреть, почему так много памяти потребляется.
    Ответ написан
  • Хочу понять алгоритм перемещания узла в дереве nested set

    @egorinsk
    Нарисуйте небольшое дерево и вручную переместите узел, и посчитайте, что поменялось.
    Ответ написан
    Комментировать
  • Как синхронизировать только структуру БД?

    @egorinsk
    Извечная проблема деплоймента. Если сайт небольшой и не-частообновляемый, то проще всего скачать ночью live базу, внести изменения, залить обратно.

    Если сайт большой, то пишут миграции — код, который апгрейдит/даунгрейдит базу с версии N на версию N + 1, также пишется скрипт, который смотрит версию БД и применяет нужные миграции.

    Но этот вариант, на мой взгляд, плох, так как код миграций надо писать руками, и это сомнительное удовольствие. Я же и так базу ковыряю запросами, почему миграции не генерировать как-то автоматически? Зачем делать все по 2 раза? А вот спросите у любителей Руби, почему им нравится делать все одну и ту же работу 2 раза.
    Ответ написан
  • Обработка большого числа $_POST

    @egorinsk
    Я бы убрал strtoupper. Он не нужен. Если программист на клиентсайде перепутал большие буквы с маленькими — пусть исправляет ошибку сам, а не скрипт за него это делает.

    Собирать запрос к БД руками — неуклюже. Я бы свалил все в массив, и передал через плейсхолдеры вроде execute(«INSERT INTO ?table (?#) VALUES (?a)», $table, array_keys($data), array_values($data))

    В остальном нормальный код, выполняющий свои функции. Хотя, конечно, кто-то предложит для этих целей сделать модели, репозитории, unit-of-work и что там еще придумал Мартин Фаулер для этих целей.

    Если вам интересно, как это можно сделать сложнее, почитайте мануалы к любому фреймворку типа Yii или Zend или Symfony или Ruby on Rails или Джанго. Там вам расскажут про модели, валидаторы, хранилища, бекенды, слои абстракции и прочие умности.

    И да, все эти ORM и фреймворки для PHP тяжелые, уродливые, и сам язык, из-за того что при каждом запросе надо инициализировать приложение заново, не позволяет их сделать нормальными, так что с точки зрения производительности лучше писать все руками.

    Но я бы такой код писать не стал, так как мне надо, чтобы свойства модели и полей формы для ее модификации хранились в одном месте, а не были раскиданы по HTML-коду, яваскриптам и PHP-обработчикам. Забудешь же потом, где что менять, когда захочется например изменить лейбл у поля ввода. Также, ваш код не умеет ни делать валидацию переданных данных (передавай что хочешь — все запишет в БД), ни маппинг/сериализацию/джейсонизацию, а мне надо, чтобы все это было.
    Ответ написан
    4 комментария
  • Подзапрос в условии ON для LEFT JOIN'а в MySQL

    @egorinsk
    Я бы лучше сделал SELECT user_id, MAX(date) FROM stats GROUP BY user_id, а потом бы приджойнил юзеров запросом из приложения вроде SELECT * FROM users WHERE user_id IN (...). Что-то я сомневаюсь, что четырехэтажные запросы с подзапросами будут быстро работать, да еще и в MySQL.
    Ответ написан
    Комментировать
  • Какой вариант логики запросов правилен?

    @egorinsk
    Только второй вариант. Не слушайте теоретиков. MySQL все эти джойны и аггрегацию никак не соптимизирует.
    Ответ написан
    Комментировать
  • Какой вариант логики запросов правилен?

    @egorinsk
    Только второй вариант. Не слушайте теоретиков. MySQL все эти джойны и аггрегацию никак не соптимизирует.
    Ответ написан
  • Стоит ли открыть исходный код ORM для PHP?

    @egorinsk
    Сам по себе ORM — банальная ничем не примечательная хрень. Это уже много раз делали в других фреймворках (например, RoR, Java) и описано в книгах про паттерны. Берешь, делаешь как в Руби и пользуешься хоть до посинения.

    Пример с User::create() неудачный: у реальных объектов бывает по 20 свойств и фукнция с 20 аргументами будет выглядеть дико. Функции с подчеркиванием в начале — уродливые. Передавать __CLASS__ и подобные магические методы тоже не очень как-то.

    Один из сложных моментов в проектировании ORM — оптимальная организация взаимодействия с хранилищем. Например, этот ваш пример:

    > foreach(UsersGroup::getPremiumMembers()->orderBy('registration_date')->limit(10) as $user){
    > echo $user->getCountry()->getCurrency()->getCode()."
    ";

    Сколько запросов сгенерирует при использовании SQL-хранилища? По идее, должно быть в районе 3-4, причем данные справочников еще бы и стоило кешировать (ибо валюты у стран меняются очень редко) и обойтись 1-2 запросами. Если у вас в цикле для каждого юзера делается запрос — хлам это, а не ORM.

    Второй момент — оверхед. Вы когда-нибудь считали, какая разница по времени выполнения запроса через ваш ORM и через mysqli_query() (включая время на загрузку и инициализацию классов ORM)? Посчитайте, наверняка у вас после этого вообще пропадет желание использовать ORMы.

    Третий момент — масштабирование. Можно ли, к примеру, сделав огромный сайт на вашем ORM, не переписывая кода, реализовать расшардивание базы на 100 серверов (чтобы справиться с нагрузкой). Можно ли на нем делать проекты уровня хотя бы игр для соцсетей или вконтакта?

    Если у вас есть решение хотя бы некоторых из описанных 3 проблем проектирования ORM, ваша статья на тему архитектурных решений и программистских хитростей была бы крайне интересна. Если нет решения — то такой орм любой школьник может сделать, как я уже сказал, прочтя мануал к рубионрейлс.
    Ответ написан
    3 комментария
  • Как лучше хранить данные в БД?

    @egorinsk
    Вариант 2 — если вам надо часто добавлять поля, то учтите, что добавление поля — это фактически создание второй копии таблицы (т.е. долго). Также, при большом числе полей растет объем таблицы, ухудшается время доступа.

    Что касается вариата 1, рассмотрите также вариант выбирать записи без JOIN, а 2 запросами — MySQL на джойнах может неэффективно работать (к сожалению, точнее сказать не могу, это надо проверять на практике).

    Я бы лично сделал вариант 1, но с кешированием в каком нибудь key-value storage.
    Ответ написан
  • PhpMyAdmin + PHP-FPM = SEGFAULT?

    @egorinsk
    Вы можете собрать/установить debug-версию и после падения отладчиком gdb посмотреть, где (в какой функции) произошла ошибка.
    Ответ написан
  • Где хранить IP пользователей?

    @egorinsk
    На 1 IP могут быть десятки. сотни, тысячи пользователей. Например, у Гугл есть специальный алгоритм определения числа пользователей за IP. Можете погуглить PDF.

    Но в вашем случае, это излишне сложно — хватит ограничения на 1 голос с IP.

    Хранить — сделайте таблицу вида user_ip INTEGER(...), article_id, vote. Такая таблица, в случае правильнйо расстановки индексов, работает быстро и легко кешируется в случае надобности.
    Ответ написан
    1 комментарий
  • MySQL кеширует запросы даже при выключенном кешировании?

    @egorinsk
    Если бы результат брался из кеша, он бы не выполнялся 1-2 секнуды, а 1-100 мс. Скорее всего, просто куски файлов с диска попадают в кеш ОС и при повторном запросе берутся из памяти.

    Если вы работаете под Линукс, кеш ОС (для чистоты эксперимента) можно сбросить записью единички куда-то в /proc (гуглите), внутренние буфера mysql сбрасываются перезапуском демона.

    Т.е. делаете service mysql stop, сбрасываете кеш ОС, service mysql start и выполняете запрос.
    Ответ написан
    Комментировать
  • Запрос для выборки комментариев

    @egorinsk
    Не слушайте этих болтунов. Для комментариев идеальный вариант — Materialized Path (уважаемые коллеги, кто предлагает Nested Sets, вы пробовали прикинуть, сколько обновлений придется сделать при вставке комментария перед 100 существующими? а перед 200?). Проблема дорогой вставки частично обходится переходом на дробные left и right key, но это сложно.

    Недостатки Materialized Path: ораниченная глубина комментариев (но можно поставить например 16 или 32 — это почти всегда хватит), ограничение на число дочерних комментариев (опять же, ставим цифру типа 65536 и не паримся — вряд ли на вашем сайте будет столько ответов).

    Смена родителя комментария — дорогая и сложная операция, но я не знаю, где это требуется.

    Плюсы: дешевая вставка (1 обычный INSERT), дешевая выборка (1 SELECT с индексом).

    Вывод: слушайте лучше мои умные советы а не этих болтунов.
    Ответ написан
    3 комментария