У меня их больше полусотни стабильно, поэтому критичен момент с памятью. Когда вкладка открывается, то загружается в память. Хром всё держит в памяти, яндекс-браузер только 10 последних. Как у вас? Я видел в меню «выгрузить вкладки» и «выгрузить неактивные вкладки». Только ручной вариант не очень удобен. Да и что понимается под неактивными? Веб-панели попадают под понятие «вкладки»?
13 открытых багов против 372. 412 закрытых против 567.
Реляционку или Key-Value можно "порезать" на части (с возможной денормализацией), отшардировать и реплицировать. Попробуйте по кластеру размазать произвольный граф. Ситуация, когда связанные компоненты окажутся на разных нодах, скорее нормальная. Это оказывает большое влияние на консистентность и производительность.
Кажется мы о разном. Я говорил о СУБД с точки зрения построения самой СУБД, а не потребительском использовании.
Если у вас всё ок с ориентом, то я рад. При наличии других решений ввязываться я не захотел.
Структура будет всё равно отличаться от колоночной базы, но результат будет близок. Например, когда нужен агрегат по колонке, будут по-прежнему считаны и ключи. Аналогичный эффект может быть получен на любой строковой БД за счет денормализации.
Что ориент, что аранго, пытаются влезть в рынок баз и представляются как универсальные хранилища. Маркетинг. Графовая база более широкая (по разнообразию моделей данных) система, чем реляционные и NoSQL решения. Да, она может вместить в себя документо-ориентированную модель. Но её универсальность не позволяет быть оптимизированной под все случаи. Плюс одна из основных проблем графовых баз — это масштабируемость (заверяют, что решили её аранго и титан). Повторюсь, не стоит брать более сложный универсальный инструмент для относительно простой задачи, где есть специализированные инструменты.
Колоночно-ориентированная субд отличается способом хранения данных. Она позволяет делать последовательные чтения с диска для получения данных из отдельных колонок. Предназначена для аналитических запросов. Часто умеет хорошо сжимать разреженные данные. Схема жестко задана. В качестве примера — формат хранения данных parquet. Данные бьются сначала на группы строк (это связанно с надежностью хранения), а внутри группы строк хранятся уже поколоночно. Схема внутри одной группы строк неизменяема.
Семейство колонок — это способ организации хранения в базах типа ключ-значение. Данные хранятся построчно. Доступ к строке по ключу. Внутри строки хранится список кортежей из двух элементов. Первый — имя колонки, второй — значение в данной строке и данной колонке. Это позволяет для каждого ключа иметь произвольный набор колонок.
А column-family (которые теперь зовут просто таблицами) у неё просто так?
Абсолютно верно, не просто так! Они потому и стали зваться таблицами, что это лучше отображает суть.
OrientDB — графовая субд, что уже переводит её в класс существенно более сложных систем. Она, мягко говоря, не вписывается в разговор.
Если говорить о применении. Пришлось недавно искать графовую базу и рассматривал в том числе OrientDB. Общая картина отзывов о ней — по началу безумный восторг, но когда проекты доходят до середины появляется ворох нерешаемых проблем. Создатели вкладываются в кучу фич, но до ума большинство не доводят, баги копятся. Принимать высокий риск вляпаться в проблемы желания не было.
Если уж очень хочется в сайтик вставить графовую базу, лучше посмотреть в сторону ArangoDB. Её позиционируют как универсальную базу удобную как раз для создания прототипов, когда модель данных может меняться. (Блин, ну 10 раз взвесьте сначала, нужна ли вам в проекте редкая сложная система, требующая других подходов. Все проблемы и вопросы придется задавать в гугл группе и ждать несколько дней ответ. При том, что в 99,99% случаев ваша модель не потребует ничего сложнее реляционности.)
Пересказ своими словами и лишь пара абзацев от себя %) Похоже надо ввести еще один тип статей помимо переводов — изложение.
Сам материал "пустой", местами даже вредный.
Если речь иет о проекте в сфере «интернета вещей», где огромное количество всевозможных устройств и датчиков генерируют гигантские объёмы данных, вполне разумно будет использовать Cassandra.
Ну вот как лишь по критерию объема данных делать выбор в пользу конкретной субд?
Если говорить о монге и проектировании приложений, то эта статья куда интереснее.
object A {
val CONST_VALUE = "CONST_VALUE"
}
class A {
def f = A.CONST_VALUE
}
Хочется иметь возможность посмотреть конкретное значение у A.CONST_VALUE. Пример сильно утрированный. Проблема возникает, константы находятся в другом файле и приходится по нескольку раз переключаться между файлами. Встречается с чужими либами, либо при работе с другими системами (Connascence of Values).
Сколько вкладок в памяти держится?
Реляционку или Key-Value можно "порезать" на части (с возможной денормализацией), отшардировать и реплицировать. Попробуйте по кластеру размазать произвольный граф. Ситуация, когда связанные компоненты окажутся на разных нодах, скорее нормальная. Это оказывает большое влияние на консистентность и производительность.
Если у вас всё ок с ориентом, то я рад. При наличии других решений ввязываться я не захотел.
Диагностировать проблемы к сожалению редко кто пытается. По тыку пальца хотят решение. Беда не только программистов.
Семейство колонок — это способ организации хранения в базах типа ключ-значение. Данные хранятся построчно. Доступ к строке по ключу. Внутри строки хранится список кортежей из двух элементов. Первый — имя колонки, второй — значение в данной строке и данной колонке. Это позволяет для каждого ключа иметь произвольный набор колонок. Абсолютно верно, не просто так! Они потому и стали зваться таблицами, что это лучше отображает суть.
Отличия между column и row oriented базами:
Если говорить о применении. Пришлось недавно искать графовую базу и рассматривал в том числе OrientDB. Общая картина отзывов о ней — по началу безумный восторг, но когда проекты доходят до середины появляется ворох нерешаемых проблем. Создатели вкладываются в кучу фич, но до ума большинство не доводят, баги копятся. Принимать высокий риск вляпаться в проблемы желания не было.
Если уж очень хочется в сайтик вставить графовую базу, лучше посмотреть в сторону ArangoDB. Её позиционируют как универсальную базу удобную как раз для создания прототипов, когда модель данных может меняться. (Блин, ну 10 раз взвесьте сначала, нужна ли вам в проекте редкая сложная система, требующая других подходов. Все проблемы и вопросы придется задавать в гугл группе и ждать несколько дней ответ. При том, что в 99,99% случаев ваша модель не потребует ничего сложнее реляционности.)
з.ы. не минусовал.
Сам материал "пустой", местами даже вредный. Ну вот как лишь по критерию объема данных делать выбор в пользу конкретной субд?
Если говорить о монге и проектировании приложений, то эта статья куда интереснее.
Хочется иметь возможность посмотреть конкретное значение у A.CONST_VALUE. Пример сильно утрированный. Проблема возникает, константы находятся в другом файле и приходится по нескольку раз переключаться между файлами. Встречается с чужими либами, либо при работе с другими системами (Connascence of Values).
Тоже о комментарии.