Этнографическое

[vit_r]

Сходил на тусовку ораклилстов, точнее любителей Оракла. (DOAG)

Было два доклада в потсдамском представительстве Оракла. Иду ночью, забредаю во дворы, ищу, естественно, красивое здание с большой красной надписью.

Фиг. Со зданием всё в порядке, стоит посреди развалин каких-то старых цехов. А вот надписи нет.

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

Интересно, что оказался не самым молодым. Было трое парней до 30 или чуть за. Судя по тому, что в костюмах и не из бизнеса, явно наши или около. Хотя, это на западе можно чётко разделить, местные все с налётом социализма. Даже те, кто родился после.

Остальные были правильные: от сорока и ближе к пенсионному возрасту. Видимо, вся молодёжь ушла в вебы и мобильники. Естественно, прилично одетых кроме официального представителя и тех двух молодых не было никого. Пара была совсем уж админского вида.

Из позитивного можно отметить не победу, но хотя бы достойное представительство феменизма. Оба доклада читала тётя. (Тоже в возрасте «за», да ещё и с ногтями разных цветов.) В аудитории было ещё три дамы на два десятка представителей стандартного пола. Правда, одна при муже, но со всякими явами и такого не бывало. Если одна какая забредала, сидела с отсутствующим лицом и правильных технических вопросов не задавала.

Лекция началась с заявления о том, что новая версия Оракла призвана экономить ресурсы, в первую очередь мозги администратора. Соответственно, у рекомендованной книжки по управлению новой версией обложка из серии «Для идиотов...» Чего-то смущает меня немного это направление движения.

Тётя радостно рассказывала про дружный делёжь ресурсов для Pluggable Databases, почему-то не затрагивая вниманием саму скорость выполнения запросов. Ещё очень правильно вместо live demonstration просто прогнала препарированную демонстрацию, то есть колоду слайдов со скриншотами, не показывая, а рассказывая, куда надо нажимать и где что писать. По-моему очень правильно. Главное, всё быстро и все ошибки заранее подготовлены, правильно показаны и объяснены мелкими недочётами в заполнении формочек.

Comments

[orleanz.livejournal.com]

я сам не спец по ораклу и не близко, но думаю, дело вот тут в чем

мощность компов растет, размеры оперативной памяти реалистичной для среднего севрера - резко растут
это все работает, мягко говоря, не в пользу релевантности "больших баз данных" типа оракла

с другой строны, мускул и постгре тоже не спят, совершенствуются, оптимизируются

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

[vit-r.livejournal.com]

Ну да. Видел я, как люди базы ваяют, не зная о третьей нормальной форме. Не зря noSQL на подъёме.

А базы растут потому, что есть тренд Big Data и люди собирают всё, что под руку попало, забивая террабайтные диски всякой ерундой.

[orleanz.livejournal.com]

" Видел я, как люди базы ваяют, не зная о третьей нормальной форме.

а причем тут 3НФ и факт, что джанго экранирует от тебя SQL?

в джанго, ты пишешь модель данных на Петоне, и там ты можешь, если тебе угодно, применить нормализацию, или не применить. это остаете полностью ТВОИМ решением. ты определеяшь, какие у тебя будут таблицы, какие в них колонки, и какие связи между ними. Ты просто делаешь это не в SQL, который для разных баз может быть немного разный, а на языке высокого уровня (в случае джанго петон, в случае рельсов руби и тп.). В результате, твое приложение может быть портировано с Мускула в Оракл путем замены слова mysql на оracle в файле настроек.

[orleanz.livejournal.com]

" адекватный декларативный язык с отображением на графическую нотацию, а не скрипы на питоне.

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

например, я бы хотел посмотрать на более понятное и просто описание такой таблицы

class Book(models.Model):

title = models.CharField(max_length=100)
author = models.CharField(max_length=100)

booktext = models.TextField()

translator = models.CharField(max_length=100)
publicationyear = models.IntegerField(null=True)

creation_time = models.DateTimeField(auto_now_add=True)
mod_time = models.DateTimeField(auto_now=True)

здесь еще бесплатный бонус - два поля для времени создания и времени апдейта. с ними вообще больше ничего не надо делать, они будут всегда правильными. колонка для primary key создатает тоже автоматически.

Это просто абсолютный предел простоты и логики. Если считаешь, что эту таблицу можно описать лучше - код в студию.

[vit-r.livejournal.com]

Нет такой технологии, которая бы не работала на элементарных примерах. Другое дело, что компьютеры сейчас настолько производительны, что пофиг, как писать.

[orleanz.livejournal.com]

это типа вы тут опровергаете сам подход, описывать структуру базы в языке фреймворка, а не SQL ?

не кажется ли вам, что противостояние ЖЖ-юзер Арбинада vs. создатели Джанго - немного комичное?

[orleanz.livejournal.com]

кстати, а где в вашем SQL примере - айди книжки, главный ключ?

[vit-r.livejournal.com]

Не надо уводить разговор. Полной постановки задачи не было.

[orleanz.livejournal.com]

ну я же написал дополнительно, что 1. автоматически добавляется ключ 2. автоматически обновляются таймстемпы

в приведенном Арбинадой голом SQL этого не было, и это надо уже потом ручками добавлять.

поэтому джанговый подход гораздо удобнее. ну и разумеется, если вдруг по какой-то дикой причине программисту НИЗАЧТО НИЗАЧТО низзя потратиться на колонку для ключа (экономия места на диске, смешно, да), то ничто не мешает ему все это сделать на простом SQL, который всегда остается для желающих поковыраться на низком уровне.

[orleanz.livejournal.com]

" А где в вашем примере оценка количества хранимых объектов класса книга?

Если у вас обычная ситуация, то вы вообще не паритесь какой ключ, и Джанко автоматические добавляет последовательно возрастающие целые числа. Первый обьект будет иметь ключ 1, второй 2 и т.д.

Если у вас НЕОБЫЧНАЯ ситуация, вам никто не мешает добавить какую угодно колонку, хоть шириной в миллион символов.

Самое смешное, что это таки очень напоминает ситуацию с упомянутым ассемблером. Ассемблер предполагает ковыряние в мелочных деталях, долго и муторно, в результате можно получить некую небольшую добавочную производительность в ряде редких случаев. В 99.9% эта мелочная оптимизация просто ненужна, и даже вредна, потому затягивает время разработки.

[orleanz.livejournal.com]

" следует заранее согласовать с DBA

о, вот тут вы и проговорились. Никакого ДВА обычно не бывает у людей использующих джанго. И юникс админа тоже нет. И вебмастера с вебверстальщиком тоже часто нет. Все делаешь сам.

если у вас есть ДБА - то значит у вас ситуация большой фирмы, множества менеджеров, миллионы скучных совещаний и согласований, миллионы диаграмм, тонны переписки в аутлуке, интриги без конца и т.д. И конечно, в этом царстве безраздельно правит Ява, Оракл и т.п. Джанго там и на порог не пускают.

[vit-r.livejournal.com]

Про удобство можно говорить, проработав несколько лет с тем и другим на серьёзных проектах.

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

[orleanz.livejournal.com]

" начинает гордиться своей некомпетентностью в области БД

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

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

вот я помню спросил 10 лет у одного оракл админа, Вит его знает кстати, Робот Бобот - каков размер базы данных которую ты пасешь, как оракл админ. Он сказал - 40 гиг. Тогда это звучало внушительно. Сейчас же, обычных сервер может легко иметь 64Гига оперативной памяти. Так что вся база может легко сидеть там. Вся работа может происходить без обращения к диску. Подумайте про это.

[orleanz.livejournal.com]

а с чего вы взяли, что я не применяю в питоне ассоциативные массивы? они называются в питоне словари и это одна из полностью нейтивных и часто используемых фич языка

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

[vit-r.livejournal.com]

Одна такая "мелочь" может увеличить производительность запросов не в разы, а на порядки.

В принципе, тезис был о том, что ресурсов завались, так что никакие разы не нужны. Всё работает и без этого.

Ну да, когда оно станет большим и страшным, будет уже поздно. Но обычно такое просто не вырастает. Да и деньги нужны сейчас, а не завтра.

[vit-r.livejournal.com]

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

[orleanz.livejournal.com]

"когда оно станет большим и страшным, будет уже поздно.

не всегда.

На Джанго работают, между прочим, такой сервис как Инстаграмм. Надеюсь, в представлении не нуждается.

Или менее известный Дискас (для управляние комментами на страницах СМИ, например)

у них, по ходу, 45 тысяч запросов в секунду (из них, 30 тысяч в секунду отбивает назад Варниш, но 15 тысяч идут на джанго, по чесноку)

http://blog.disqus.com/post/62187806135/scaling-django-to-8-billion-page-views

[vit-r.livejournal.com]

Магия вуду.

Хотя, у Фейсбука интереснее. They have a small team, so they make very specific changes to Linux and MySQL to support their use cases. Longer term changes are made by others. (http://highscalability.com/blog/2010/11/4/facebook-at-13-million-queries-per-second-recommends-minimiz.html)

[orleanz.livejournal.com]

" Магия вуду.

скорее, просто сама архитектура простая и логичная

а то, ведь как оно часто бывает. сначала бизнес-консультанты нагородят двести таблиц, с запутанными связями между ними. В основном, конечно, для повышения собственной значимости. А потом нанимают программистов которые весь этот хаус программируют. Потом выясняется, что все дико тормозит. Тогда напимают еще кучу Оракл-гуру которые пытаются навести в этом хаосу порядок и спасти ситуацию оптимизациями и магией вуду.

а по хорошему, надо было в самом начале дать по рукам бизнес-аналитикам, которые двести таблиц придумали.

вот я не удивлюсь, если у Инстаграмма и Дискаса на самом деле там штук пять таблиц всего.

[vit-r.livejournal.com]

У Инстаграмма и Дискаса достаточно простая логика. Бизнес-приложения гораздо интереснее.

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