Previous Entry Share Next Entry
2016-01

Про Оперу и NoSQL

Значит, про Оперу.

Это сейчас вебкит, но (1) быстрее (2) HighDPI поддерживается нормально.
Но. Чтобы можно было пользоваться, надо зайти в Settings-Browser, включить галку Advanced Settings, потом включить появившуюся галку "Show full URL in combined search and address bar".

И про NoSQL.

До меня внезапно дошло, что 70% всего хайпа и увеличения производительности - это последствия перехода от списков на множества (INTEGER PRIMARY KEY AUTOINCREMENT -> key-value store).

А прирост производительности потому, что операции SET/CLEAR имеют более простую семантику и лучше композятся, нежели APPEND/REMOVE_AT (в частности, их можно гораздо свободнее реордерить и повторять), и в большинстве случаев семантики SET/CLEAR достаточно.

Choose your data structures and primitives carefully, то-сё.

This entry was originally posted at http://wizzard.dreamwidth.org/379650.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
dmih July 8th, 2014
HighDPI в Хроме починили практически в последние месяцы (это я по high-DPI планшету с Windows 8 наблюдаю, ну Surface 2 Pro который).
Месяца 4 назад вообще пользоваться было нельзя, сейчас вроде вообще всё нормально.

Edited at 2014-07-08 05:45 pm (UTC)

wizzard0 July 8th, 2014
Странно, у меня он как блурился так и блурится. Вот прямо сейчас даже. При том, что движки одинаковые.

Chrome: Version 35.0.1916.153 m
Opera: Chrome/35.0.1916.153 Safari/537.36 OPR/22.0.1471.70

dmih July 8th, 2014
Отключи в свойствах ярлыка эмуляцию low-dpi.

wizzard0 July 8th, 2014
А, собственно много ускорения работы от lazy session loading, в моем случае :)

То есть, начало тормозить - убил браузер, перезапустил, осталась в памяти только активная таба :)

dmih July 8th, 2014
Вообще ускорение загрузки или там всякое вот такое меня перестало беспокоить, т.к. Хром вис или глючил последний раз ну примерно год назад. Может пол года. Не суть, в общем он как часы работает на самом деле.
А вот с возможностью открыть 150 вкладок как была жопа, так и есть. Опера тут явно не в помощь. Поэтому не суечусь.

altmind July 10th, 2014
с highdpi в хроме что-то произошло. теперь canary отображает графику масшабированой, результат отличается от обычного хрома.
https://www.dropbox.com/s/u9k8vneql6jfqxk/chrome-highdpi.png

_winnie July 8th, 2014
не понял про SET/CLEAR и APPEND/REMOVE_AT :(

В контексте "динамического массива" vs "хеш-таблица" что-то ознаётся, а в контексте баз данных - нет. В структурах баз данных ведь никогда не делают REMOVE_AT с обязательным заполнением освободившейся дырки

wizzard0 July 8th, 2014
Достаточно APPEND.

(Deleted comment)
(Deleted comment)
(Deleted comment)
juan_gandhi July 8th, 2014
Хм, звучит красиво, но как-то уж слишком просто.

Во-первых, весь этот дурдом с уникальными целочисленными айди в сиквельных базах не имеет никакого теоретического основания. Ну в смысле ради гарантии перечислимости - так оно в базе и так перечислимо. Без них там вполне множества, как и задумано было.

А так в сиквеле вполне можно ничего не модифицировать, а просто класть поверх новую версию, а брать последнее. Я так делаю в одной экспериментальной таблице. Экспериментальной потому, что так, блин, никто не поступает.

wizzard0 July 8th, 2014
> Без них там вполне множества, как и задумано было.

Это да. Но sometimes implementation details and defaults matter. А к самому языку (SQL) у меня в этом плане претензий нет.

EDIT: Кстати, современные Postgres и ORCL вроде умеют GUID primary key, если я ничего не путаю...

Edited at 2014-07-08 06:19 pm (UTC)

dmih July 8th, 2014
У MS-SQL-я есть API для работы с внутренними ключами, по которым он там на низком уровне ходит. Я делал, получается с одной стороны эффективно, с другой стороны эти ключи пипец большие и неудобные в отладке.
В целом это всё напопинало написание биллинга на ассемблере и не очень мне понравилось, выигрышь был небольшой.

(Deleted comment)
109 July 8th, 2014
пользы от использования автоинкрементных суррогатных ключей [для кластерного индекса] ровно две.

1. новая запись добавляется всегда в конец => no page splits on inserts
2. как известно, некластерные индексы несут в себе кластерный ключ. поэтому чем меньше байт занимает кластерный ключ, тем меньше места занимают индексы => less IO and more cache hit %

109 July 8th, 2014
начиная со слов "NOSQL" у меня только один коммент: чё? :)

wizzard0 July 8th, 2014
Это мысли вслух после курения кое-каких сорцов и чтения Oracle Internals.

  • 1
?

Log in

No account? Create an account