> На практике оказывается, что спецподдержка Юникода в языке часто приводит к проблемам, не помогая при этом решить ни одной практически важной задачи.
Я в шоке… то-то я мучался с кодировками 15 лет назад при поддержке десятка языков в ASCII сборках Win32.
Теперь, когда у меня во всем стеке прозрачный Юникод и я просто могу работать со строками не заморачивась, даже когда у меня арабский с английским перемешан, я думал, что у меня все в порядке.
А оказывается, я только себе проблемы создаю, и лучше вернуться к однобайтным строкам?!?!
Partitioning в PostgreSQL, к сожалению, весьма ограниченный и неудобный. Пользоваться можно, но с оговорками.
Я его пока удачно приспособил только для данных похожих на логи, которые копятся со временем, редко читаются, и должны удаляться по истечении какого-то срока (но при этом все-равно требуют транзакций и не могут писаться в простые файлы).
В этом случае удобно чистить хвост.
Пробовал прикрутить к среднего размера таблицам (пока до 100 миллионов записей, то есть еще не требуют разбиения, но могут в перспестиве вырасти в 10-100 раз), в которых ожидал видимый эффект от разбивки данных по годам и клиентам (горячими являются только 1-2 последних года, и запросы почти всегда только по одному клиенту. Но на данный момент накладные расходы планировщика запросов привели к ухудшению производительности на десяток процентов, вместо улучшения.
Думаю, когда таблицы вырастут раз в 10, эффект уже должен проявиться.
Напрягает еще ограничение на количество разделов — во всех источниках не рекомендуют иметь более чем несколько десятков партиций. А если я только задумаюсь делить данные по клиентам и по годам (что мне казалось очень логичным, учитывая отсутствие пересечений между ними, ну, почти всегда), то количество разделов легко вырастает за пределы рекомендуемого.
мы активно используем Groovy скрипты для всяких нестандартных задач (импортов или расчетов), запускаемых по расписанию. Так мы их сознательно запускаем в режиме интерпретатора, без компиляции. Но это сделано на основе теоретических опасений, так сказать, во избежание. Интересно, насколько проблема нами выдумана…
Недавно столкнулся с тем, что 17 гиг на gmail (получили еще 2 за какой-то опрос) уже почти закончились — пришлось поискатьписьма размером более мега и поудалять всякую фигню — помогло на пару гиг…
А не возникает проблем с каким-нибудь мусором от класс-лоадера в случае, если такие скрипты массово запускаются по расписанию, и соответственно постоянно перекомпилируются?
Навигация по таблицам классная — переходы между foreign keys и фильтрация по полю (местами хромает, но в основном работает).
Для коллекции пожеланий (nice-to-have, конечно) — общие:
— поддержка right-to-left языков (типа арабского и иврита), хотя и стала получше, но все еще хромает, по сравнению с Eclipse или SquirrelSQL.
Для PostgreSQL — было-бы неплохо:
— лучше поддерживать нестандартные типы данных, такие как HSTORE… не знаю, как насчет JSONB — у меня его пока нет (застряли на 9.1)
— как-то поддерживать PostGIS данные — это было-бы круто, хотя это, конечно, и огромная тяжелая фича.
А есть какие-то гайды по написанию плагинов для улучшения поддержки таких нестандартных типов данных? Я погуглил немного, но ничего не нашел…
Расчет смещения по конкретному часовому поясу для исторических данных будет всегда возвращать одинаковое локальное время для исторических дат, не взирая на решения текущего правительства по смене зимнего/летнего времени или даже смене часового пояса для конкретной местности — все изменения будут касаться только будущих дат.
Как правильно заметили выше, будущие даты возможно придется корректировать, особенно если в данной местности сменили сам часовой пояс. Но не прошлые даты (за крайне редким исключением баг фиксов в исторических часовых поясах — я видел пару таких случаев, вроде-бы).
Я так понимаю, товарищ говорил о том, чтобы вместе с временем сохранять ID часового пояса (типа 1='America/Los_Angeles')
Тогда время может быть корректно рассчитано даже при изменении зимнего/летнего времени или часовых поясов.
Если я правильно понимаю, осовная фича timestamptz заключается в том, что значение автоматически сохраняется в UTC в соответствии с текущим часовым поясом, и при запросах соответственно преобразуется обратно?
Предположим, мы говорим не о базе, которая работает в рамках одного единственного часового пояса, а паралельно с пользователями из разных часовых поясов.
Не лучше-ли сохранять в базе UTC и делать преобразования ближе к front-end-у?
Мне кажется, тогда можно кешировать больше данных, так как на уровне базы данных и бизнес-логики можно работать в UTC, с однородными данными.
Итог: игра превзошла все ожидания создателей, и даже оказалась эффективнее рекламы на телевидении. За три месяца в игре приняло участие больше 5 миллионов юзеров, которые наиграли в общей сложности 3000 часов.
3000 часов поделить на 5М человек — это по 2 секунды на нос… открыли и сразу закрыли?
Было-бы неплохо в начале статьи уточнить, что такое RFP. Особенно если статья ориентирована на заказчиков, которые не в курсе терминологии разработчиков.
То, что описано в статье, я привык называть SRS — Software Requirements Specification, она составляется не заказчиком, а разработчиком (как правило, так как заказчик крайне редко обладает необходимыми навыками).
Я проработал пару лет с этой мышью, пока не сломал кнопку, и решил поменять на такую-же, но словил проблемный экземпляр с «отскоком» (описанным в статье) — к счастью, поменяли по гарантии без проблем (хотя и отправили мышь в сервис. центр на проверку на неделю).
Эргономика мне очень нравится, пока мне пришлось временно пользоваться маленькой мышкой, сразу почувствовал проблемы с рукой, в то время как с этой мышью никаких проблем.
И бесконечный скроллинг — суперская фича — раскручиваешь колесо, и страница прокручивается, куда надо, пока не остановишь.
Хотя качество Logitech в последние годы, конечно, уже не то, что раньше.
На одной из прошлых работ HR обращала внимание на кандидатов с муз. образованием/способностями и связывала способности к музыке со способностями к математике, и соответственно — плюс для программеров.
Затрудняюсь сказать, насколько это правдиво :-)
Мне лично гитара помогает вечером мозги прочищать, после дня за компом.
Как правило, народ начинает заниматься реверс-инжинирнгом когда они сталкиваются с проблемой, которая никак не решается нормальными способами, и Oracle не способен помочь… как-то мне кажется странным, что куче народа просто нефиг делать и они реверс инжинирингом по-приколу занимаются…
Интересные (лично для меня, но возможно и для других) темы:
1. Визуализация данных, полученых от простых REST Web Services — JSON или XML.
2. Возможности рассылки таких интерактивных отчетов другим (избранным) людям — например, менеджерам внутри организации
3. Возможности внедрения таких интерактивных отчетов в сторонние веб-сайты (внутренний сайт компании — естественно, не публичный).
Я в шоке… то-то я мучался с кодировками 15 лет назад при поддержке десятка языков в ASCII сборках Win32.
Теперь, когда у меня во всем стеке прозрачный Юникод и я просто могу работать со строками не заморачивась, даже когда у меня арабский с английским перемешан, я думал, что у меня все в порядке.
А оказывается, я только себе проблемы создаю, и лучше вернуться к однобайтным строкам?!?!
Что я не так понимаю в жизни? :-)
Я его пока удачно приспособил только для данных похожих на логи, которые копятся со временем, редко читаются, и должны удаляться по истечении какого-то срока (но при этом все-равно требуют транзакций и не могут писаться в простые файлы).
В этом случае удобно чистить хвост.
Пробовал прикрутить к среднего размера таблицам (пока до 100 миллионов записей, то есть еще не требуют разбиения, но могут в перспестиве вырасти в 10-100 раз), в которых ожидал видимый эффект от разбивки данных по годам и клиентам (горячими являются только 1-2 последних года, и запросы почти всегда только по одному клиенту. Но на данный момент накладные расходы планировщика запросов привели к ухудшению производительности на десяток процентов, вместо улучшения.
Думаю, когда таблицы вырастут раз в 10, эффект уже должен проявиться.
Напрягает еще ограничение на количество разделов — во всех источниках не рекомендуют иметь более чем несколько десятков партиций. А если я только задумаюсь делить данные по клиентам и по годам (что мне казалось очень логичным, учитывая отсутствие пересечений между ними, ну, почти всегда), то количество разделов легко вырастает за пределы рекомендуемого.
Для коллекции пожеланий (nice-to-have, конечно) — общие:
— поддержка right-to-left языков (типа арабского и иврита), хотя и стала получше, но все еще хромает, по сравнению с Eclipse или SquirrelSQL.
Для PostgreSQL — было-бы неплохо:
— лучше поддерживать нестандартные типы данных, такие как HSTORE… не знаю, как насчет JSONB — у меня его пока нет (застряли на 9.1)
— как-то поддерживать PostGIS данные — это было-бы круто, хотя это, конечно, и огромная тяжелая фича.
А есть какие-то гайды по написанию плагинов для улучшения поддержки таких нестандартных типов данных? Я погуглил немного, но ничего не нашел…
Расчет смещения по конкретному часовому поясу для исторических данных будет всегда возвращать одинаковое локальное время для исторических дат, не взирая на решения текущего правительства по смене зимнего/летнего времени или даже смене часового пояса для конкретной местности — все изменения будут касаться только будущих дат.
Как правильно заметили выше, будущие даты возможно придется корректировать, особенно если в данной местности сменили сам часовой пояс. Но не прошлые даты (за крайне редким исключением баг фиксов в исторических часовых поясах — я видел пару таких случаев, вроде-бы).
Тогда время может быть корректно рассчитано даже при изменении зимнего/летнего времени или часовых поясов.
Предположим, мы говорим не о базе, которая работает в рамках одного единственного часового пояса, а паралельно с пользователями из разных часовых поясов.
Не лучше-ли сохранять в базе UTC и делать преобразования ближе к front-end-у?
Мне кажется, тогда можно кешировать больше данных, так как на уровне базы данных и бизнес-логики можно работать в UTC, с однородными данными.
Заголовок статьи сразу привлекает внимание — суперский заголовок, многообещающий… эти навыки помогут «на любом tech собеседовании»…
3000 часов поделить на 5М человек — это по 2 секунды на нос… открыли и сразу закрыли?
Было-бы неплохо в начале статьи уточнить, что такое RFP. Особенно если статья ориентирована на заказчиков, которые не в курсе терминологии разработчиков.
То, что описано в статье, я привык называть SRS — Software Requirements Specification, она составляется не заказчиком, а разработчиком (как правило, так как заказчик крайне редко обладает необходимыми навыками).
Эргономика мне очень нравится, пока мне пришлось временно пользоваться маленькой мышкой, сразу почувствовал проблемы с рукой, в то время как с этой мышью никаких проблем.
И бесконечный скроллинг — суперская фича — раскручиваешь колесо, и страница прокручивается, куда надо, пока не остановишь.
Хотя качество Logitech в последние годы, конечно, уже не то, что раньше.
Затрудняюсь сказать, насколько это правдиво :-)
Мне лично гитара помогает вечером мозги прочищать, после дня за компом.
И вы только iPhone собираетесь подключать?
1. Визуализация данных, полученых от простых REST Web Services — JSON или XML.
2. Возможности рассылки таких интерактивных отчетов другим (избранным) людям — например, менеджерам внутри организации
3. Возможности внедрения таких интерактивных отчетов в сторонние веб-сайты (внутренний сайт компании — естественно, не публичный).