Ой, ну фиг знает… Я как-то в последнее время не парюсь по поводу денег — раньше это был основной критерий отбора, но сейчас мне важен лишь интересный проект и вменяемый коллектив. Параллельный своей работе проект я вообще делаю бесплатно, just for fun по мере сил и наличия времени. Мне до сих пор предлагают куда большие деньги, чем я получаю сейчас, но как-то не тянет пока — еще здесь работа есть, да и надоело мне с места на место перебегать. Я человек холостой, но родителей активно поддерживаю, так что можно сказать, что семейный по полному комплекту))) Денег хватает выше крыши, хоть и не потолок, а всего лишь выше среднего. У меня зарплата сейчас серая — основная денежная масса попадает на руки, оставшаяся оседает на карточке, к которой я напрочь забыл пин-код и не парюсь — тока вчера зашел в банк, чтобы снять с нее денег и купить мега-гитару забавы ради. Что касается инфляции, то я либо что-то не то и не там покупаю, либо просто не ощущаю ее эффекта — бензин как был год назад рублей 20, так и остался… Даже подешевел рубля на три)))
Сникерсы может быть и подорожали, но совсем по другой причине ;)
А вот вопрос такой: у нас есть свой почтовый сервер, реверс-днс прописан, но мы устраиваем рассылки по своей клиентской базе. За один таск может быть отправлено по несколько сотен тысяч писем. Как не попасть в блэк-лист в таком случае?
Внедрение всякого рода ERP может доходить до очень больших сумм. Значительно превосходящих стоимость более-менее нормального проекта.
А что касается 100 000 рублей, то это всего лишь зарплата толкового и опытного программиста в условиях финансового кризиса.
Конечно же в memcached реализовано магическое сжатие, позволяющее сжать всю вселенскую информацию, скажем, в один гиг и извлекать из нее крохотные кусочки со скоростью света +))))
В memcached зашит обычный RCU: данные, которые реже запрашиваются — первые кандидаты на убийство, когда заканчивается память, выделенная memcached'у, а это на нагруженных проектах случается, хоть и нечасто с учетом стоимости памяти и объема хранимых в нем данных (у нас сейчас, например, забито всего 1.3 гига и 173 метра свободно).
В базах тот же самый RCU + инвалидация при изменении таблиц, входящих в запрос. С одной стороны это конечно хорошо — база гарантировано очистит кэш, если данные поменяются, но с другой стороны — это просто отвратительно, поскольку база грохнет кэш, независимо от того, затронули ли изменения возвращаемые строки и/или их количество или нет.
С помощью ByKey можно несколько записей привязать к одному ключу, но только к одному. То есть, грохнув этот ключ, мы грохнем все записи, с ним ассоциированные. И сделано это ни разу не для теггирования — это дает возможность разносить записи по «виртуальным серверам» в терминологии libmemcached, которые в свою очередь могут быть размещены на одном или нескольких физических серверах.
Исходники я не смотрел, но судя по тому, что они говорят «The larger the the set of nodes, the fewer misses that will occur. » каждый виртуальный сервер — на низком уровне ни что иное, как обычная запись в мемкэше. То есть выборка getByKey($serverKey, $recordKey) двухэтапная — сначала делаем get($serverKey) по всем серверам из нашего кластера, затем к полученной хэш-таблице get($recordKey). Перегон хэш-таблицы (которая может быть достаточно больше) из памяти в память — сомнительное мероприятие в плане производительности.
Возможно, эта либа более интеллектуальная — в первом проходе она запоминает сервер, на котором был найден виртуальный сервер и слабы, в которых он содержится, а на втором только к этим слабам применяется поиск по аггрегатному ключу ($serverKey, $recordKey). Тогда все более производительно (не ищем записи там, где их гарантировано нет), но более сложно.
Очевидно, что ничего общего с тегированием не имеет.
Ну да… самые полезные классы — это первый, где меня научили писать (и то я кроме росписи каллиграфический почерк не использую вообще — пишу печатными буквами) и десятый, где я за год изучил весь школьный курс геометрии, большую часть школьной алгебры и кое-какие вещи, убранные из общей программы…
Сколько помню себя, любовь к компьютерам началась где-то года в 4 с игры Wolfenstein… Мне бы тогда гуру какого-нибудь по программированию и математике, желательно с палкой для погонки осла — до сих пор с завистью смотрю на ровесников, которые легко копаются в ассемблере и сях.
Нет. Получился шикарный фрэймворк для маппинга постгресных типов в пхпшные и обратно. Фишка не в том, что можно массивы туда-сюда гонять, а в том, что можно сделать отображение своих композитных типов постгри, любой сложности в PHP-шные ассоциативные массивы.
А если мы можем легко мапить типы, значит сможем также легко мапить хранимые процедуры. Маппер у Димы тоже есть — сам жду документации, поскольку я его использую, как выяснилось, не так, как задумывал автор %)
Сникерсы может быть и подорожали, но совсем по другой причине ;)
А что касается 100 000 рублей, то это всего лишь зарплата толкового и опытного программиста в условиях финансового кризиса.
В memcached зашит обычный RCU: данные, которые реже запрашиваются — первые кандидаты на убийство, когда заканчивается память, выделенная memcached'у, а это на нагруженных проектах случается, хоть и нечасто с учетом стоимости памяти и объема хранимых в нем данных (у нас сейчас, например, забито всего 1.3 гига и 173 метра свободно).
В базах тот же самый RCU + инвалидация при изменении таблиц, входящих в запрос. С одной стороны это конечно хорошо — база гарантировано очистит кэш, если данные поменяются, но с другой стороны — это просто отвратительно, поскольку база грохнет кэш, независимо от того, затронули ли изменения возвращаемые строки и/или их количество или нет.
С помощью ByKey можно несколько записей привязать к одному ключу, но только к одному. То есть, грохнув этот ключ, мы грохнем все записи, с ним ассоциированные. И сделано это ни разу не для теггирования — это дает возможность разносить записи по «виртуальным серверам» в терминологии libmemcached, которые в свою очередь могут быть размещены на одном или нескольких физических серверах.
Исходники я не смотрел, но судя по тому, что они говорят «The larger the the set of nodes, the fewer misses that will occur. » каждый виртуальный сервер — на низком уровне ни что иное, как обычная запись в мемкэше. То есть выборка getByKey($serverKey, $recordKey) двухэтапная — сначала делаем get($serverKey) по всем серверам из нашего кластера, затем к полученной хэш-таблице get($recordKey). Перегон хэш-таблицы (которая может быть достаточно больше) из памяти в память — сомнительное мероприятие в плане производительности.
Возможно, эта либа более интеллектуальная — в первом проходе она запоминает сервер, на котором был найден виртуальный сервер и слабы, в которых он содержится, а на втором только к этим слабам применяется поиск по аггрегатному ключу ($serverKey, $recordKey). Тогда все более производительно (не ищем записи там, где их гарантировано нет), но более сложно.
Очевидно, что ничего общего с тегированием не имеет.
Сколько помню себя, любовь к компьютерам началась где-то года в 4 с игры Wolfenstein… Мне бы тогда гуру какого-нибудь по программированию и математике, желательно с палкой для погонки осла — до сих пор с завистью смотрю на ровесников, которые легко копаются в ассемблере и сях.
А если мы можем легко мапить типы, значит сможем также легко мапить хранимые процедуры. Маппер у Димы тоже есть — сам жду документации, поскольку я его использую, как выяснилось, не так, как задумывал автор %)