?

Log in

No account? Create an account

Entries by category: дизайн

http://www.google.com/search?q=Column-Stores+vs.+Row-Stores%3A+How+Different+Are+They+Really%3F

Column-Stores vs. Row-Stores: How Different Are They Really?


Daniel J. Abadi, Samuel R. Madden, Nabil Hachem, 2008



«Row store» и «column store» — два разных способа организации хранения данных. Распространённые SQL системы — MySQL, MS SQL, PostgreSQL — используют row stores: записи в таблицах хранятся в виде последовательности структур, каждая из которых содержит значения для соответствующих колонок. Альтернативным способом хранения является column store (MonetDB, Vertica (C-Store)): в отдельных структурах данных (упрощённо — файлах) последовательно хранятся содержимое ячеек для одной колонки, затем — для другой, и далее для всех колонок.

Column store дизайн представляет возможность использовать следующие оптимизации:
  • Колонки, имеющие низкую вариативность содержимого, могут хорошо сжиматься. В row stores рядом с полем с низкой вариативностью (пол) будет соседствовать поле B с высокой вариантивностью (номер телефона), усложняя или делая невозможным компрессию. Отсутствие подобных «лишних» данных в файле колонки позволяет с успехом использовать простые схемы компрессии, типа RLE.
  • При необходимости делать запросы, которые возвращают только небольшое подмножество колонок из таблицы, системы column store читают только содержимое тех колонок, которые участвуют в запросе. При большом количестве данных это пропорционально снижает количество данных, которые нужно прочитать с диска.
  • Поздняя материализация: данные из нескольких колонок собираются в кортежи на как можно более поздних этапах выполнения запросов.
  • Блочная итерация: значения передаются внутри итераторов обработчика запроса как блоки, а не как серии кортежей.

Бытует мнение, что некоторые из преимуществ, предоставляемых column stores, можно имитировать с использованием чуть более усложнённой схемы данных в row stores. Например, для таблицы, в которой N колонок, но выборка чаще всего производится по определённым M из них (M < N), имеет смысл создать отдельную табличку, включающую только те поля, которые используются в запросах. Также можно поиграться материализованными представлениями, либо делать index-only планы с комбинированными ключами.

Данная статья рассматривает тест TPC-H (несколько таблиц в «звёздной» схеме) на нескольких миллионах записей, и пытается применить все оптимизации row stores, которые призваны имитировать часть функциональности column stores. С противоположной стороны, берётся column store, и из неё последовательно выбрасываются все оптимизации, специфичные для column stores (например, отключается компрессия колонок).

Вывод статьи следующий:


Среднее время выполнения тестов TPC-H было в районе 4 секунды для column store, и 80..220 секунд для row store. Даже при использовании наилучшего сценария для row stores — использования материализованных представлений, которые были специально сделаны под запросы, которые были заранее известны — column stores выиграла: 4 с. vs. 10.2 с.

Никакие из попыток имитировать column stores не были особенно успешными. Вертикальное партиционирование неплохо работает в случае M < ¼N, но при ином отношении избыточное количество служебной информации (заголовки кортежей, избыточные копии идентификаторов записей) начинает доминировать в структуре I/O, и преимущество вертикального разбиения теряется. Index-only планы вынуждают объединять колонки используя дорогие hash джойны на TPC-H схеме, что существенно замедляет запросы. Материализованные представления дают наилучший результат в каких-то случаях, но в некоторых случаях bitmap-объединения могут быть медленнее, чем чисто последовательные сканы.

Что касается тех вещей, которые наиболее сильно влияют на преимущество column stores, то было показано, что компрессия и поздняя материализация дают наибольший вклад (10x и 3x, соответственно).

Отдельным вкладом статьи является то, что авторы предложили ещё одну оптимизацию column stores, а именно «invisible join», которая позволяет иногда ускорить column stores ещё процентов на 50—75.

Tags:

Сергей Булаев (Интернетные штучки, etc) наткнулся на известный эффект различия в идеологии многооконной работы между маком и виндой.

Не знаю почему, но стоит виндоузятнику сесть за мой ноут, скажем проверить почту, первым делом производится попытка увеличить окно браузера до максимума. И это при разрешении монитора 1920x1200. Я давно уже отвык от этих странностей.

Это абсолютно стандартная практика, проверенная уже на десятках друзей. Единственное что я могу предположить - походу в винде, в отличии от маков, не особо удобно работать с несколькими окнами на десктопе.
http://bulaev.org/10150221

Этот эффект неоднократно описан в литературе по UI дизайну, и замечается достаточно быстро с переходом на мак.

По дефолту (без использования плагинов типа MegaZoomer, RightZoom) мак не позволяет распахнуть окна на полный экран — зелёная кнопка делает что-то неуловимое глазу, меняя форму окна, но окно на полный экран так и не разворачивает. Новичок в маках чертыхается и затем отучается щёлкать по этой зелёной кнопке, образуя бардак на своём столе из множества нераспахнутых окон, перекрывающих друг друга. А затем к нему приходит друг, и пытается, в свою очередь, щёлкнуть по зелёной кнопке в желании распахнуть очередное окно. А оно не работает — форма окна меняется, но как-то странно, неочевидно. И так происходит круговорот в природе.



В чём прикол? В маках зелёная кнопка со значком плюсик не предназначена для распахивания окна на полный экран. В наш век экранов с двухтысячепиксельными разрешениями мало какое приложение может рационально отобразить информацию на таком пространстве. Открой тот же браузер на полный экран — и все эти «тянущиеся» дизайны, не говоря уж про plain text, превратятся в набор длинных строк. Длинные строки — это зло, пока переносишь взгляд от правого края экрана до левого, ты забываешь на какой строчке этот взгляд должен в итоге остановиться. Ширина строчек в книгах — 60-70 букв по горизонтали, не больше. Журнальная и газетная вёрстка — и того у́же, и не без причины. Распахивание на полный экран — неработоспособная парадигма для современных разрешений.

Вместо этого на маках предлагается другая модель для распахивающего действия. Эта модель удивительно проста, но абсолютно неочевидна, если ты сталкиваешься с ней впервые.

Нажатие на зелёную кнопку убирает скроллбары.

Иными словами, нажатие зелёной кнопки приводит к тому, что окно начинает расширяться направо и вниз (а если не получилось — то двигается влево и вверх) пока содержимое окна (документ, веб страница) не сможет отобразиться в этом окне полностью, не приводя к необходимости интерфейсу отрисовывать к окну вертикальные или горизонтальные скроллбары.

Не во всех приложениях эта модель уместна. Например, как в текстовом редакторе без концепции постраничной разбивки (TextEdit, это что-то типа Notepad) определить, влез контент, или нет, если мы пишем свободно перетекающий в зависимости от размеров окна долгий текст? Для подобных приложений зелёная кнопка может работать несколько иначе. Но основной момент именно таков — зелёная кнопка расширяет окно до размера контента в нём.

Что применённая эпловцами модель действия зелёной кнопки даёт на практике? Первый эффект, это то что пользователь — хорошо ли это, или плохо — отучается распахивать окна на весь экран. Видимо, в глубокой фрустрации от процесса нажимания на зелёную кнопку. Второй эффект — это то, что в полном соответствии со Стокгольмским синдромом пользователь начинает находить для себя в этой патовой ситуации положительные моменты. При работе над приложениями виден весь контекст: можно одновременно работать в текстовом редакторе, браузере и фотошопе не занимаясь переключением окон. Все они видны на экране одновременно. Из-за того, что в маке настоящий драг-н-дроп, открытые и видные одновременно приложения этот драг-н-дроп стимулируют и поощряют.

Естественно, контекста может быть слишком много: никому не нравится, когда из его экрана торчит множество одновременно движущихся червяков и выедают мозг. Защита от распыления внимания на маке состоит из следующих моментов:
  • Реальный, (почти) удобный механизм рабочих столов. Да, как на юниксах. В отличие от винды, в которой приложения упорно не желают мириться с разными десктопообразующими тулзами, и постоянно брыкаются. В итоге разные активности просто размещаются в разных рабочих пространствах, группируясь по любым критериям, типа "работа1", "работа2", "развлечения", и поэтому один визуальный контекст с несколькими одновременно видимыми приложениями не мешает другому.

  • В маке нет этих вечных всплывающих балунов. Сеть воткнули, выткнули, потеряли устройство, вставили устройство, нужен апдейт, апдейт устанавливается, апдейт установлен, антивирус протух, антивирус просканировал и не нашёл, антивирус просканировал, нашёл и полечил, etc. Эти вещи назойливо вмешиваются в рабочий процесс даже если распахиваешь какое-то окно на полный экран. Винда просто задолбает асинхронными нотификациями. Мак обычно таких вещей себе не позволяет.


Так всё же, как более удобно, с распахиванием окон на полный экран, или без этого? Думаю, что лучше всего иметь гостевой комп с виндой, если уж гости такие гики, что предпочитают клавиатуру водке.

Tags:

Profile

lionet
Lev Walkin
Website

Latest Month

December 2016
S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728293031

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by yoksel