Я не знаю как в винде, боженька миловал, но в линуксе кэш занимает всю память :) и он там, несколько упрощая, тоже LRU. И если уж вы решили поработать со своим кэшированием, то возможно стоит поиграться вокруг O_DIRECT, потому что иначе все чтения все равно будут в пейджкэш подниматься
Про индекс вы правы, по TEXT может быть и обычный, я правда что-то не вижу длины индексируемого префикса в DDL, он там вроде обязательный. В любом случае spatial типы в мускуле - такое себе.
Во-первых, вам не нужен кэш - ОС и так кэширует данные с диска, причем сразу страницами по 4 КиБ. Во-вторых, никак не обыгран readahead — когда программа читает с какого-то места в файле, ОС, разумно полагая, что чтение продолжится и дальше, читает не только то что запросили, а достаточно много сверх того (128 КиБ по дефолту в линуксе, емнип). То есть можно сикать по файлу так, чтобы в память поднималось по 64К сзади и 64К спереди, для пущей эффективности.
Там сверху упоминали mmap - может быть, работать так точно удобнее, но по факту скорее всего не быстрее, чем обычный файловый IO, а может быть и медленнее - надо бенчмаркать.
И да, ничего удивительного в том, что вы обыграли MySQL, ведь у вас hash_value - не VARCHAR, а TEXT (это очень неэффективный способ хранить строки), и индекс по нему - полнотекстовый, а не b-tree или какой там по дефолту :)
Я бы сказал что планку качества сдвинул рынок - это нам всем не нужны нормальные, оттестированые ОС и программы, по-крайней мере на десктопах. В макоси тоже все катится вниз по наклонной
Насколько я понял, это пистолет чтоб, грубо говоря, держать на прикроватной тумбочке и отстреливаться от жуликов, проникших ночью в дом. То есть требования к нему весьма противоречивые:
Быстрая готовность к действию, возможно спросонья и в состоянии стресса
Безопасность, чтобы ни жулики, ни детишки не могли взять и начать стрелять
Сейчас такое решается всякими разными сейфами со сканерами отпечатков итд.
Если серьезно, то именовать ресивер this - это плохая практика именно из-за семантики ресивера - thing.Func(args...) это всего лишь синтаксический сахар над (T).Func(thing, args...). В терминах С++ это все статические функции, и абсолютно легально вызывать их с нулевым ресивером (оф дока даже несколько издевательски утверждает, что _как правило_ все функции прекрасно работают с нулевым ресивером, но на практике это скорей фантастика :) )
Потому что го хоть и сделан для тупых (сурс), но все-таки предполагается что память среднего го-программиста получше, чем у среднего джависта, которому рыбка Дори даст фору в способности держать контекст, так что не надо писать GetSomethingFromAnotherThingByNameAndTimeStamp()
Если им никогда не было надобности - то никто и не научится. А было бы очень неплохо если бы современные программисты хоть немножечко понимали, как работает сеть :)
Ну, мой опыт относится к компаниям масштаба нескольких тысяч инженеров (не всего сотрудников, а инженеров). Это еще гаражная разработка?
Менеджмент тут совершенно не при чем, я говорил исключительно про техническую часть работы. Все это разделение - это кмк вредная сверхспециализация, которая мешает, во-первых, холистическому, системному взгляду на продукт, а во-вторых, размывает овнершип.
Я работал в обеих моделях и по разные стороны баррикад (и кодером, и админом), и вот такая модель, когда человек или команда владеет всем жизненным циклом своего продукта, от проектирования до эксплуатации - на мой взгляд, наиболее здоровая и продуктивная. По сути, на это можно даже с определенной натяжкой смотреть как продолжение идей (оригинального, а не того, во что это в итоге вылилось) девопса и прочих «-опсов», когда стены между отделами совсем разрушились и все смешались.
После строительства Асуанской ГЭС Нил уже перестал разливаться бесконтрольно.
Да и земледелие сейчас уже не зависит от речного ила, потому что минеральные удобрения.
Я не знаю как в винде, боженька миловал, но в линуксе кэш занимает всю память :) и он там, несколько упрощая, тоже LRU. И если уж вы решили поработать со своим кэшированием, то возможно стоит поиграться вокруг O_DIRECT, потому что иначе все чтения все равно будут в пейджкэш подниматься
Про индекс вы правы, по TEXT может быть и обычный, я правда что-то не вижу длины индексируемого префикса в DDL, он там вроде обязательный. В любом случае spatial типы в мускуле - такое себе.
Хорошая попытка, но матчасть слабовата.
Во-первых, вам не нужен кэш - ОС и так кэширует данные с диска, причем сразу страницами по 4 КиБ.
Во-вторых, никак не обыгран readahead — когда программа читает с какого-то места в файле, ОС, разумно полагая, что чтение продолжится и дальше, читает не только то что запросили, а достаточно много сверх того (128 КиБ по дефолту в линуксе, емнип). То есть можно сикать по файлу так, чтобы в память поднималось по 64К сзади и 64К спереди, для пущей эффективности.
Там сверху упоминали mmap - может быть, работать так точно удобнее, но по факту скорее всего не быстрее, чем обычный файловый IO, а может быть и медленнее - надо бенчмаркать.
И да, ничего удивительного в том, что вы обыграли MySQL, ведь у вас
hash_value
- не VARCHAR, а TEXT (это очень неэффективный способ хранить строки), и индекс по нему - полнотекстовый, а не b-tree или какой там по дефолту :)Это и называется рынок, да
Я бы сказал что планку качества сдвинул рынок - это нам всем не нужны нормальные, оттестированые ОС и программы, по-крайней мере на десктопах. В макоси тоже все катится вниз по наклонной
Книжку читал, хорошая :)
Много чего было сломано и похоронено, но гет, как говорится, за фактс - микрософт же реально цветет.
Гугл, Микрософт, Адоб, АйБиЭм, Мастеркард, Пепси, даже, прости-господи, онлифанс. Это уже не шовинизм, это уже легкое отрицание реальности :)
Сатья мсфт реально вытащил из болота.
В 2018 году в микрософте от линейных инженеров до Сатьи было 6-7 уровней руководства. Где-то такое же число в других подобных конторах.
Очень упрощая и генерализируя, можно иерархию плюс-минус вот так выстроить:
Линейный менеджер - менеджер потолще - директор направления - директор орга - випи - СТО - СЕО
Насколько я понял, это пистолет чтоб, грубо говоря, держать на прикроватной тумбочке и отстреливаться от жуликов, проникших ночью в дом. То есть требования к нему весьма противоречивые:
Быстрая готовность к действию, возможно спросонья и в состоянии стресса
Безопасность, чтобы ни жулики, ни детишки не могли взять и начать стрелять
Сейчас такое решается всякими разными сейфами со сканерами отпечатков итд.
https://mermaid.live/ (DSL для умл и прочих флоу чартов)
Отрадно читать что линукс на десктопе все еще держит марку :)
Если серьезно, то именовать ресивер this - это плохая практика именно из-за семантики ресивера -
thing.Func(args...)
это всего лишь синтаксический сахар над(T).Func(thing, args...)
. В терминах С++ это все статические функции, и абсолютно легально вызывать их с нулевым ресивером (оф дока даже несколько издевательски утверждает, что _как правило_ все функции прекрасно работают с нулевым ресивером, но на практике это скорей фантастика :) )Потому что го хоть и сделан для тупых (сурс), но все-таки предполагается что память среднего го-программиста получше, чем у среднего джависта, которому рыбка Дори даст фору в способности держать контекст, так что не надо писать GetSomethingFromAnotherThingByNameAndTimeStamp()
/s
Анекдот про хакеров и солонку, да :)
Например, в Эстонии и Литве isikukood/asmens kodas прикрепляется к человеку и не будет меняться если он уезжает и возвращается
Ответ прост - Василиск Роко
О да, еще больше сраного софта, который никто не понимает, как работает - это именно то, что нужно индустрии в данный момент.
Да ничего, еще полгодика в таком же духе - и оставшиеся разъедутся.
Если им никогда не было надобности - то никто и не научится. А было бы очень неплохо если бы современные программисты хоть немножечко понимали, как работает сеть :)
Ну, мой опыт относится к компаниям масштаба нескольких тысяч инженеров (не всего сотрудников, а инженеров). Это еще гаражная разработка?
Менеджмент тут совершенно не при чем, я говорил исключительно про техническую часть работы. Все это разделение - это кмк вредная сверхспециализация, которая мешает, во-первых, холистическому, системному взгляду на продукт, а во-вторых, размывает овнершип.
Я работал в обеих моделях и по разные стороны баррикад (и кодером, и админом), и вот такая модель, когда человек или команда владеет всем жизненным циклом своего продукта, от проектирования до эксплуатации - на мой взгляд, наиболее здоровая и продуктивная. По сути, на это можно даже с определенной натяжкой смотреть как продолжение идей (оригинального, а не того, во что это в итоге вылилось) девопса и прочих «-опсов», когда стены между отделами совсем разрушились и все смешались.