Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 15   вперед  Ctrl
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
roden
И наверное, тогда Вы тоже знаете, как реализован этот тест. Соответственно, вывод тоже сможете сделать о его объективности ...

Я не очень понимаю, что Вы в данном случае подразумеваете под объективностью. Про любой тест можно сказать, что он субъективен и назвать случаи, которым он не очень соответствует. В то же время, очевидно, делать проект в N версиях дабы выбрать из них лучшую СУБД для этого проекта - очевидно, неоправданно дорого. Тесты дают возможность получить работоспособное приближение к верному ответу. Не нравится TPC-H? Предложите лучше. Про TPC-H можно сказать, что благодаря составу участников он обеспечивает если не "объективность", то "равноудалённую субъективность", что вполне неплохо.

roden
А ЛИНТЕР ... тот самый

Угу. Если отбросить рекламный шум - ясно, что защищённость противоречит производительности, это не вызывает никакого протеста и желания критиковать. Как нишевый продукт, Линтер имеет вполне себе репутацию. Но когда ко мне приходят с вопросом из того же Росатома - я, абстрактно, хотел бы знать, какую именно просадку в производительности я получу, приобретая эту защищённость.

roden
Не хотите опрос среди завсегдатаев провести о полезности TPC-H?

Нет. Зачем?
7 окт 15, 11:54    [18245643]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
softwarer
Нет. Зачем?

А как иначе Вы узнаете сколько завсегдатаев юзают СУБД, которым не нужен виноград в виде TPC-H? Которые ждут каких-то более объективных вещей. Например, второго места в каком-нибудь конкурсе, куда брендов не пускают.
7 окт 15, 12:15    [18245800]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
Случайный посетитель
Guest
softwarer
Случайный посетитель
пропущено...
Ну, и какую долю в решении этих задач составляет поиск где бы применить килер-фичу от используемой СУБД?

Примерно такую же, какую у Вас по утрам составляет поиск, на что бы натянуть штаны.
Так и запишем: доля использования - практически нулевая.
Хотя, может быть, у кого-то ноги, на которые обычно натягиваются штаны, живут отдельной жизнь, и их надо специально разыскивать...
7 окт 15, 13:17    [18246286]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
Ермаков Михаил
Member

Откуда: Воронеж
Сообщений: 41
softwarer
roden
А ЛИНТЕР ... тот самый

Угу. Если отбросить рекламный шум - ясно, что защищённость противоречит производительности, это не вызывает никакого протеста и желания критиковать. Как нишевый продукт, Линтер имеет вполне себе репутацию. Но когда ко мне приходят с вопросом из того же Росатома - я, абстрактно, хотел бы знать, какую именно просадку в производительности я получу, приобретая эту защищённость.


В нашем случае с нашими ограничениями - до 5% (в подавляющем большинстве случаев).
Основные затраты на безопасность:
1. шифрование (если есть).
2. мандатная защита.

Шифрование применяется только при подкачке в кэш и выталкивании из него. В текущих условиях достаточности памяти для подавляющей части БД эти затраты будут незначительными (объём шифрования журналов обычно тоже невелик, ибо модификаций не так много). Хотя допускаю, что есть задачи в которых производительность процессора при шифровании будет ограничением (SSD+ большой поток модификаций+мелкие транзакции+++).

Проверки мандатной защиты в нашем случае представлены в виде проверок по матрицам. Благодаря ограничениям на количество групп и уровней которые могут быть максимально в системе (250 и 10 соответственно), мы можем организовать эффективную матрицу проверки сразу на обращении к данным - без вызова функции сравнения для каждой записи в отдельности. Кроме того, формат хранения на диске подразумевает отсутствие метки для поля (наследование с уровня записи) при условии, что она не задана специально для данного поля. (При этом, указанные нами ограничения в реальной системе по нашим оценкам не являются проблемой.)

Если интересует ещё какая-то информация связанная с этими вопросами - обращайтесь.
7 окт 15, 13:49    [18246614]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
roden
Member

Откуда:
Сообщений: 741
softwarer
roden
И наверное, тогда Вы тоже знаете, как реализован этот тест. Соответственно, вывод тоже сможете сделать о его объективности ...

Я не очень понимаю, что Вы в данном случае подразумеваете под объективностью.

Под объективностью можно подразумевать только тоже, что и все нормальные люди

softwarer
roden
И наверное, тогда Вы тоже знаете, как реализован этот тест. Соответственно, вывод тоже сможете сделать о его объективности ...

В то же время, очевидно, делать проект в N версиях дабы выбрать из них лучшую СУБД для этого проекта - очевидно, неоправданно дорого.

Зачем эти крайности? Кто сказал, что для объективного анализа необходимо делать полный проект в N версиях? Неужели на поставленной и понятной Вам задаче Вы по-другому не можете?

softwarer
Про TPC-H можно сказать, что благодаря составу участников он обеспечивает если не "объективность", то "равноудалённую субъективность", что вполне неплохо.

Всё же выборочно Вы меня читаете, но напишу ещё раз: Вам интересно будет посмотреть на результат, "подогнанный" при помощи хинтов? Сколько их тех запросов, которые используются в TPC-h, будут использоваться у вас?



softwarer
roden
А ЛИНТЕР ... тот самый

Угу. Если отбросить рекламный шум - ясно, что защищённость противоречит производительности, это не вызывает никакого протеста и желания критиковать. Как нишевый продукт, Линтер имеет вполне себе репутацию. Но когда ко мне приходят с вопросом из того же Росатома - я, абстрактно, хотел бы знать, какую именно просадку в производительности я получу, приобретая эту защищённость.

Пока реализации защиты лучше, чем в ЛИНТЕР, я не видел. Причем в сравнении с другими решениями с небольшой просадкой производительности.
А что в Oracle с мандаткой большая просадка? :)

softwarer
roden
Не хотите опрос среди завсегдатаев провести о полезности TPC-H?

Нет. Зачем?

Что бы Ваше мнение о полезности TPC-H не оказалось субъективнее, чем Вам думалось.
7 окт 15, 13:55    [18246690]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
Случайный посетитель
Так и запишем: доля использования - практически нулевая.

Передёргиваете. Не "доля использования", а "доля поиска".

Случайный посетитель
Хотя, может быть, у кого-то ноги, на которые обычно натягиваются штаны, живут отдельной жизнь, и их надо специально разыскивать...

Верно. И именно такой кто-то задаёт вопросы про "поиск где бы применить килер-фичу от используемой СУБД?" У нормальных людей таких вопросов не возникает, у них процесс обратный - приходит клиент с желанием ну хотя бы полнотекстового поиска по договорам, а дальше либо используется фича СУБД, либо... медленно и печально.
7 окт 15, 14:15    [18246881]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
Q.Tarantino
Member [заблокирован]

Откуда: Где-то рядом...
Сообщений: 12015
IMHO roden просто пиарит продукт, который внедряет его контора, причем с пеной у рта.
Или мне одному так показалось?
7 окт 15, 15:05    [18247284]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
Q.Tarantino
IMHO roden просто пиарит продукт, который внедряет его контора, причем с пеной у рта.
Или мне одному так показалось?

roden этим занимается уже лет десять, все давно привыкли. На форуме были-есть несколько таких персонажей. По каше пара человек. По версанту был. Вот и по Линтеру.
7 окт 15, 15:07    [18247309]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3795
softwarer
Q.Tarantino
IMHO roden просто пиарит продукт, который внедряет его контора, причем с пеной у рта.
Или мне одному так показалось?

roden этим занимается уже лет десять, все давно привыкли. На форуме были-есть несколько таких персонажей. По каше пара человек. По версанту был. Вот и по Линтеру.

и Юрий!!
7 окт 15, 15:18    [18247426]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Q.Tarantino
IMHO roden просто пиарит продукт, который внедряет его контора, причем с пеной у рта.

А как по Вашему ему бы следовало пиарить? Все таки у него, скорее всего, не такой продукт, которому не мешают всякие там TPC-H тесты. Что делать то? Что?
7 окт 15, 15:28    [18247533]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
Q.Tarantino
Member [заблокирован]

Откуда: Где-то рядом...
Сообщений: 12015
А линтер реально кто-то юзает из форумчан, кроме rodena?
7 окт 15, 15:31    [18247566]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Q.Tarantino
А линтер реально кто-то юзает из форумчан, кроме rodena?

Q.Tarantino
А линтер реально кто-то юзает из форумчан, кроме rodena?

Так а разве его мало?
Впрочем, можно попробовать в искалке посмотреть в разделе "Использование СУБД".
7 окт 15, 15:41    [18247650]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
Q.Tarantino
А линтер реально кто-то юзает из форумчан, кроме rodena?

я хотел перевести наше дело в постгри и линтер
с постгри все обошлось за неделю ( формально все работает, а производительность и т.д. пока не нестировали - тема пока заглохла с импортозамещением)
а у линтера много ограничений (и в принципе пока никто не настаивает)
7 окт 15, 16:39    [18248086]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
roden
Member

Откуда:
Сообщений: 741
ViPRos
а у линтера много ограничений
Какие ограничения мешают?
7 окт 15, 17:40    [18248569]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
roden,

прошло больше месяца, так что список не могу озвучивать
а так
1. типы данных
2. длина стринг полей
3. кажется что то с бигинт
...

длина наименований объектов кажись
какие то проблемы с batch SQL
там еще более солидные ограничения какие то были
да еще и нет нашел инфраструктуры (не смог выгрузить из МССКЛ метамодель - возможно из за этого и особых усилий не приложил)

я сразу параллельно переводил на Линтер, Постгри и Оракл - без анализа их возможностей
первым делом отпал Оракл - минимализм в наименования объектов не дал продвинуться дальше коннекшна
вторым отпал Линтер (ну, это скорее временно, как только будут настойчиво требовать продвину дальше)
Постгри дошел до конца (тоже пришлось выкручиваться с batch SQL)

оказалось что MSSQL намного более подготовлена для динамической работы чем все остальные (ну Оракл раньше всех отпал по другой причине, потому не могу настаивать)
7 окт 15, 18:01    [18248766]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
конечно наверняка МССКЛ просто мне ближе (только с ним я в основном и реально работал)
7 окт 15, 18:03    [18248775]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
невозможность передать параметры в batch просто взбесило в Постгри
7 окт 15, 18:07    [18248798]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
ViPRos
первым делом отпал Оракл - минимализм в наименования объектов не дал продвинуться дальше коннекшна

Это ограничение, конечно, достаёт, когда работаешь с данными, но я не понимаю, как оно может составлять проблему для системы, выстроенной на метамодели. В нескольких местах, где решается задача "преобразовать id объекта в физическое имя" вставляешь, ну например, md5 от слишком длинной строки - и проблема решена. Или хоть тот же id используешь как имя.
7 окт 15, 18:11    [18248815]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
softwarer,

ну я ж не говорю что невозможно
тут уже куча прикладных вещей написана с учетом уже имеющихся имен
возможно это просто архитектурный ляп мой, не подумал что когда то придется работать с другими СУБД
ну и на Оракл заказа воще не было, это я хотел попутно иметь и потому при первом затыке оставил на потом
7 окт 15, 18:17    [18248869]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
а так мне надо еще одно наименование ввести (4-ый по счету) и разделить БД имя от Программного
7 окт 15, 18:20    [18248875]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
хотя изначально я этому противлюсь упорно
7 окт 15, 18:37    [18248953]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
ViPRos
а так мне надо еще одно наименование ввести (4-ый по счету) и разделить БД имя от Программного

Ну не знаю. Я как-то сразу закладывал, что есть название (в смысле - текстовая строка, которая выводится в интерфейсе), есть имя объекта (как он должен называться в базе), а есть представление этого имени, как он должен фигурировать в запросах (в случае mssql-я, например - как '[' + имя_объекта + ']'). Соответственно, последнее из них вычисляется соответствующим методом адаптера БД.
7 окт 15, 18:45    [18248985]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
softwarer,

ну у меня три имени
но программное имя и имя в хранилище совпадает - и это сделано осознанно
модельное имя и интерфейсное - тут все ясно
но я не хочу что бы один и тот же объект назывался в СКЛ так а на допустим c# по другому (сложно все это потом интерпретировать)
я тогда изучил проблему маппинга имен и пришел к выводу, что это ересь
а вот модельное имя - это особое, тут можно добиться некоторой увязки с языком естественным (хотя бы одним - инвариантом)
так как я не думал и не думаю что кто то будет продавать ВИПРОС за рубеж я выбрал русский как язык системы (с учетом госязыка заказчика)
и когда я строю понятийный граф или открываю тезаурус, то перед глазами осмысленный контекст на русском, причинно - следственные и другие аспектные вещи
и мне ваще очень хочется плюнуть на эти прикладные задачи и программирование всяких кейс средств и переключится на семантические изыски
но никто не хочет эту работу оплачивать
я например уверен что мог бы анализировать любую более менее нормализованную структуру и дать ответ о ее полноте и избыточности и т.д. с разных точек зрения и т.д.
море интереснейших задач на уровне естественного языка
7 окт 15, 19:03    [18249053]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
ViPRos
Member

Откуда:
Сообщений: 9967
softwarer,

'[' + имя_объекта + ']'). - я сделал типа метод "нейтрализатор", который пытается эти вещи привести к стандарту
7 окт 15, 19:05    [18249060]     Ответить | Цитировать Сообщить модератору
 Re: Импортозамещение СУБД для хранилищ данных и для OLTP  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67475
Блог
ViPRos
но я не хочу что бы один и тот же объект назывался в СКЛ так а на допустим c# по другому (сложно все это потом интерпретировать)

С одной стороны, да. С другой - у каждого инструмента свои возможности и ограничения. Пихая одну строку в несколько инструментов, оказываешься перед выбором: либо твои требования к строке должны быть объединением всех требований всех инструментов, либо придётся по необходимости трансформировать её под инструмент. Первый путь мне решительно не нравится. Ну, грубо - представь, что ты работаешь на MSSQL и C#, но вынужден ограничиваться именами длины 30, поскольку это требование Оракла.

ViPRos
'[' + имя_объекта + ']'). - я сделал типа метод "нейтрализатор", который пытается эти вещи привести к стандарту

Не понял мысль.
7 окт 15, 19:23    [18249126]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 15   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить