Почему же, важно. Просто некоторые кандидаты имеют дополнительные навыки (также указанные в объявлении), перевешивающие затраты на обучение, и сами готовы «переехать» на другой стек. Я всего навсего имел ввиду, что требования в объявлении это не святые скрижали, не обязательно требовать от кандидатов абсолютного соответствия.
Всякое бывает… Иногда интервью не туда уходит и создает неправильное мнение о кандидате — очень сильно зависит от опыта интервьюора. Или «химии» нет между кандидатом и предположим тим лидом будущим, который его интервьюирует.
Кандидат может быть классным специалистом но не вписываться в команду/компанию из-за разницы в менталитете/характере/корпоративной культуре/etc.
Дать фидбек в таком случае очень тяжело, так как это не претензии к профессиональным качествам, а просто «не сошлись характерами».
Опять-же — это не значит, что кандидат — плох. Это место для него — не подходит (плохое).
Куча кандидатов, по CV выглядящие достойно, не могут ответить на простейшие вопросы.
И есть кандидаты с очень похожими CV (и меньшим опытом), отвечают на порядок (если не на два) лучше.
Так что собеседование отсеивает кучу народа (к сожалению, так как времени занимают одинаково).
А на требования кандидаты зачастую смотрят не внимательно, да и я сам эти требования воспринимаю как чисто рекомендательные, только как примерный первичный фильтр — чтобы кандидат знал, что ему примерно ожидать.
К примеру, мы работаем с Java, но неоднократно принимали разработчиков пришедших с .NET. А по логике соответствия требованиям вакансии, они не должны были даже CV нам отправлять. Однако — отправили, и великолепно вписались в команду.
К сожалению, в больщинстве случаев критический (а он другим быть не может в случае отказа) отзыв кандидатом как правило воспринимается негативно и персонально (как переход на личности). У меня тоже поначалу было желание «помочь» и подсказать — я пару раз обжегся и начал отправлять формальные отказы.
Вместо прозрачного и понятного HTML + JS (каждый на 2-5 строк) — приличный кусок кода, который приходится анализировать и вдумываться — а что оно делает… даже не смотря на некоторое знакомство с React
Но если бОльшая часть запросов к последнему периоду, то должны поиметь профит :)
Много запросов типа — дай последний месяц (два, три) или последний год. Если у нас сейчас январь — все такие запросы захватят два раздела, и будет медленней. То есть тогда эффект от разбиения данных на разделы будет исключительно когда индексы перестанут в память влезать.
У Вас только 2 партиции: архив и текущая?
Тогда можете и не заметить ускорения.
Почему? Если их побить так, чтобы все 99% запросов попадали в текущий раздел, и только редкие исторические — в архив, в этом есть смысл.
Но по-видимому, в любом случае нужно плавающее окно для текущего раздела, а не YEAR == 2000.
Ну так ежу понятно… Я-ж о том, что надо либо дофига данных, чтобы разбиение начало давать эффект, либо чтобы подавляющее большинство запросов гарантированно работали только с одним разделом.
А в моем случае, при разбивке по календарным годам, всегда есть период, в который практически ВСЕ запросы будут попадать в границу и захватывать два раздела.
Я думал, что может сделать первый раздел на 2 года, но как плавающее окно, а архивные уже по годам.
Но тогда нужно периодически (раз в месяц или несколько) мигрировать данные в архив — и это будет тяжелая операция, включающая перестроение разделов и их CONSTRAINTS — и мне это не сильно нравится.
Я пробовал разбивать таблицу с несколькими миллионами записей на партиции (ну, подготовиться на вырост), причем запросы идут в 99% случаев только к одной-двум партициям, но нашел, что разницы в производительности нет, а с работой по двум даже проседает из-за объединения и поиска результатов. Идея была разбить данные по годам, так как старые данные нужны редко, но работа на стыке двух лет портит всю малину.
Мы работаем в сельском хозяйстве, и практически все агрономы говорят о вреде ГМО культур для сельскохозяйственных земель. После устойчивых к гербицидам культур, которые позволяют фермерам активно использовать гербициды, на этой земле ничего больше нельзя выращивать, кроме таких-же модифицированных культур. Теоретически, не обязательно злоупотреблять гербицидами, но устойчивость основной культуры позволяет фермерам забивать болт на экономию химикатов.
Хотя в Java и проще, но все равно большое количество сторонних библиотек зачастую приводит к проблемам.
Сам сталкивался и со сменой лицензий, и прекращением поддержки, и (вдруг, при попытке обновления библиотеки) несовместимости зависимостей с другими библиотеками. По жтим причинам некоторые тяжеловесные сторонние библиотеки нам пришлось вынести в независимые процессы — чтобы избежать конфликтов зависимостей.
Я начал недавно рефакторить код и избавляться от Joda Time — многие из описаных вещей, особенно runtime exceptions из-за несовместимости многих преобразований или из-за отсутствия часового пояса, усложняют процесс.
Хотя при анализе становится понятно, что поведение действительно логично и корректно, но процесс разработки это не упрощает.
Также поначалу выстаиваются довольно дикие цепочки из вызовов (особенно когда надо сохранять обратную совместимость и все преобразовывать из/в старую Date). Тянет написать какой-то best practices guide для внутреннего использования.
Статья замечательная и очень подробная. Мне только кажеться, что вы зря обошли вниманием Java 8 — лучше было-бы все примеры пояснять на новых классах, чем объяснять кривизну старых.
На простых запросах проблем нет, и оно действительно цепляет пару разделов (партиций). На логах у меня тоже отлично работает, как я выше написал.
А в больших таблицах с данными у меня, к сожалению, много JOIN-ов со связанными таблицами, и планировщик в определенный момент решает, что ему сначала выгодней сделать JOIN по одной из связей (в принципе логично так как выборка будет маленькая), и только потом фильтровать по времени. А разбивка на партиции производится по времени, и тут логика работы планировщика для одной таблицы уже не совсем подходит. У меня не было времени еще разбираться детальнее, я только пробные эксперименты проводил, из которых и сделал вывод о спорных результатах для моего конкретного случая.
Пример показать не могу — нужно воспроизводить на каких-то искуственных данных, которые можно показывать, и отлаживать на них же.
All constraints on all partitions of the master table are examined during constraint exclusion, so large numbers of partitions are likely to increase query planning time considerably. Partitioning using these techniques will work well with up to perhaps a hundred partitions; don't try to use many thousands of partitions.
… Партиционирование с применением этих техник будет работать хорошо, вероятно, до 100 разделов (партиций); не пытайтесь его использовать с несколькими тысячами разделов.
Согласитесь, даже устаревший UCS-2 и сравнение строк, не учитывающее умляуты/лигатуры/акценты, все же лучше работы с потоком байт. Просто если язык худо-бедно поддерживает Unicode, от стандартные UI виджеты его тоже поддерживают. В старых VC++ и Delphi, в неюникодных исполняемых файлах, это были просто танцы с песнями.
А для правильной нормализации/сортировки можно ICU прикрутить.
Альтернативы Юникоду, при всех его недостатках, не будет — слишком много переписывать.
простите, но я не понимаю вашего ответа — без аргументации он не имеет смысла
я знаю про кучу проблем, которые я в прошлом имел с однобайтными кодировками, когда половина текста могла состоять из вопросиков (потому что кодировки были и близко не совместимы), клиенты ругались на потерянные названия файлов и т.п.
Я и сейчас зачастую имею такие проблемы, когда я получаю здоровые Shapefile из ArcGIS с полигонами, которые по незнанию клиенты сохраняют в локальной кодировке, и я ее должен угадывать, тыкая пальцем в небо (так как клиенты понятия не имеют о кодировках).
С UTF-8 и Unicode у меня таких проблем нет.
Что я делаю не так? Почему вы меня убеждаете, что я евангелист, и моя жизнь с однобайтными кодировками должна улучшиться? Я честно не понимаю…
Да, к этому нужно стремиться. Даже если ответ — отрицательный.
Кандидат может быть классным специалистом но не вписываться в команду/компанию из-за разницы в менталитете/характере/корпоративной культуре/etc.
Дать фидбек в таком случае очень тяжело, так как это не претензии к профессиональным качествам, а просто «не сошлись характерами».
Опять-же — это не значит, что кандидат — плох. Это место для него — не подходит (плохое).
И есть кандидаты с очень похожими CV (и меньшим опытом), отвечают на порядок (если не на два) лучше.
Так что собеседование отсеивает кучу народа (к сожалению, так как времени занимают одинаково).
А на требования кандидаты зачастую смотрят не внимательно, да и я сам эти требования воспринимаю как чисто рекомендательные, только как примерный первичный фильтр — чтобы кандидат знал, что ему примерно ожидать.
К примеру, мы работаем с Java, но неоднократно принимали разработчиков пришедших с .NET. А по логике соответствия требованиям вакансии, они не должны были даже CV нам отправлять. Однако — отправили, и великолепно вписались в команду.
Вместо прозрачного и понятного HTML + JS (каждый на 2-5 строк) — приличный кусок кода, который приходится анализировать и вдумываться — а что оно делает… даже не смотря на некоторое знакомство с React
Много запросов типа — дай последний месяц (два, три) или последний год. Если у нас сейчас январь — все такие запросы захватят два раздела, и будет медленней. То есть тогда эффект от разбиения данных на разделы будет исключительно когда индексы перестанут в память влезать.
Почему? Если их побить так, чтобы все 99% запросов попадали в текущий раздел, и только редкие исторические — в архив, в этом есть смысл.
Но по-видимому, в любом случае нужно плавающее окно для текущего раздела, а не YEAR == 2000.
А в моем случае, при разбивке по календарным годам, всегда есть период, в который практически ВСЕ запросы будут попадать в границу и захватывать два раздела.
Я думал, что может сделать первый раздел на 2 года, но как плавающее окно, а архивные уже по годам.
Но тогда нужно периодически (раз в месяц или несколько) мигрировать данные в архив — и это будет тяжелая операция, включающая перестроение разделов и их CONSTRAINTS — и мне это не сильно нравится.
Сам сталкивался и со сменой лицензий, и прекращением поддержки, и (вдруг, при попытке обновления библиотеки) несовместимости зависимостей с другими библиотеками. По жтим причинам некоторые тяжеловесные сторонние библиотеки нам пришлось вынести в независимые процессы — чтобы избежать конфликтов зависимостей.
Я начал недавно рефакторить код и избавляться от Joda Time — многие из описаных вещей, особенно runtime exceptions из-за несовместимости многих преобразований или из-за отсутствия часового пояса, усложняют процесс.
Хотя при анализе становится понятно, что поведение действительно логично и корректно, но процесс разработки это не упрощает.
Также поначалу выстаиваются довольно дикие цепочки из вызовов (особенно когда надо сохранять обратную совместимость и все преобразовывать из/в старую Date). Тянет написать какой-то best practices guide для внутреннего использования.
А в больших таблицах с данными у меня, к сожалению, много JOIN-ов со связанными таблицами, и планировщик в определенный момент решает, что ему сначала выгодней сделать JOIN по одной из связей (в принципе логично так как выборка будет маленькая), и только потом фильтровать по времени. А разбивка на партиции производится по времени, и тут логика работы планировщика для одной таблицы уже не совсем подходит. У меня не было времени еще разбираться детальнее, я только пробные эксперименты проводил, из которых и сделал вывод о спорных результатах для моего конкретного случая.
Пример показать не могу — нужно воспроизводить на каких-то искуственных данных, которые можно показывать, и отлаживать на них же.
… Партиционирование с применением этих техник будет работать хорошо, вероятно, до 100 разделов (партиций); не пытайтесь его использовать с несколькими тысячами разделов.
А для правильной нормализации/сортировки можно ICU прикрутить.
Альтернативы Юникоду, при всех его недостатках, не будет — слишком много переписывать.
я неправильно понял ваш предыдущий комментарий…
я знаю про кучу проблем, которые я в прошлом имел с однобайтными кодировками, когда половина текста могла состоять из вопросиков (потому что кодировки были и близко не совместимы), клиенты ругались на потерянные названия файлов и т.п.
Я и сейчас зачастую имею такие проблемы, когда я получаю здоровые Shapefile из ArcGIS с полигонами, которые по незнанию клиенты сохраняют в локальной кодировке, и я ее должен угадывать, тыкая пальцем в небо (так как клиенты понятия не имеют о кодировках).
С UTF-8 и Unicode у меня таких проблем нет.
Что я делаю не так? Почему вы меня убеждаете, что я евангелист, и моя жизнь с однобайтными кодировками должна улучшиться? Я честно не понимаю…