ну а теперь вопрос по существу, допустим есть портал, реализованный на mySQL, теперь надо опертивно запоминать есть ли такой то пользователь на сайте. для этого я бы использовал SQLite.
было бы неплохо если б Yii поддерживал несколько конекшонов к разным базам даных
и неск. конекшонов к одной базе. у обычного пользователя свои полномочия, у администратора сайта свои
to carat
Yii вполне отлично поддерживает работу с несколькими базами данных.
Quote
Какая-то общая фраза не имеющая ничего общего с реальностью. Даже если Вы готовы каждый раз доставать из кармана сотни тысяч баксов для очередного абгрейда железа (что вряд ли), в тупик (как в плане мощности железа, так и финансовый) Вы зайдете гораздо раньше чем сможете обслуживать даже треть того количества людей, о котором написали.
Нагрузки на сервер БД (исходя из планируемого количества пользователей онлайн) должны быть решены на этапе планирования приложения. И одим из ключевых шагов этого решения является выбор СУБД. Здесь общее описание подобных проблем и пути решения. http://www.insight-i…e-bazy-dannykh/. При использовании методов описанных в статье, специфика работы с сервером БД определяется на УРОВНЕ КОДА. Кроме решений описанных в статье, некоторые СУБД (не MySQL) позволяют реализовать физическое масштабирование базы на несколько физически разных машин на уровне самого сервера БД…
Добавлю-ка и я свою ложку “мёда” в эту флудильню 
…
Кстати, собирались же флудить в другой ветке… Жизнь - штука сложная 
Итак, поехали!
Гл. ув. тов. Zolter, никто никакую чушь тут кроме Вас не несёт. Начиналось, мне кажется, с очень (на первый взгляд) безобидной фразы: "Юзайте постгрес или оракл - и не будете знать проблем ". Попробуйте, поюзайте постгрес или оракл, и Вы столкнетесь с таким количеством проблем, что иногда даже возникнет желание вообще всё бросить и плюнуть на разработку.
Это я к тому, что везде свой порог вхождения. С MySQL работать научиться проще всего (mysql -uroot, и понеслось… или вообще - phpmyadmin). Те, кто постоянно работает с MySQL не задумываются чаще всего вообще ни о связях, ни от транзакциях (некоторые даже не догадываются зачем всё это надо, поверьте).
Продолжаем, никто с Вами и не спорит и не пытается сказать, что Вы неправ. Все, кажется, сходятся в том, что "для каждой задачи есть свой инструмент". И я с этим полностью согласен. Колоть орехи мобильником, конечно, можно, но лучше для этого что-нибудь другое (молоток, например).
Не до конца понимаю иронии со стороны dikoy'ого по поводу использования Yii в серьёзном проекте. Того функционала, который уже есть мне хватает. Что ещё нужно для веб-приложений?.. Что требуется - достаточно легко написать в виде расширения к Yii. Сырость фреймворка дает о себе знать, конечно, да и разработчик по сути один - Qiang, что не очень радует (тьфу-тьфу-тьфу, вдруг заболеет?).
Про росто вширь/вверх/вглубь/вбок и т.д. сами разбирайтесь. Я, вообще, считаю, что у каждого есть своё мнение и оно не всегда может сходиться с мнением остальных. И при этом он будет даже прав, а все будут заблуждаться - и такое тоже часто бывает.
В заключение, хочу задать такой вопрос (мне не очень хотелось его задавать и я долго терпел): "Zolter, а Вы программный код так же пишете, как и текст по-русски? У вас ошибок столько же? Читать очень неприятно."
Сразу прошу за это прощения, но немного наболело читать неграмотный текст, местами очень уж похожий на "падонкаффский" стиль.
P.S. В отношение последнего вопроса и в целом возникает такое чувство, что тов. Zolter ещё юн и у него мелькает юношеский максимализм, который он выражает таким большим количеством, в принципе, никому не нужного текста.
Sergei Kuznecov,
Некто не говорит "юзайте постгрес и оракл и и не будете знать проблем". я говорю о том что не стоит зацикливаться на одном мускуле, что инструменты в виде оракла и постгреса создавались отнюдь не желания разработчиков выпендрится. жаль что прочитав так много текста вы не вникли в саму суть которую я хотел вам объяснить. ну да ладно. просто не надо кидать фраз что мускул спасет мир.
по поводу ошибок, уж извините, пишу быстро, не всегда замечаю ошибок и не всегда могу их исправить. да, "падонкаффский" стиль тоже взял своё, и мне кажется это мое право использовать его или нет. мне жаль что вас это раздражает, но всем не угодишь.
п.п.с в отношении последнего вопроса и в целом отвечаю что кол-во текста я написал ровно столько сколько необходимо что бы доказать свою точку зрения. что я "юн" конечно сильно сказано, но к старикам я себя не отношу.
номер раз. господа, давайте все-таки называть вещи своими именами.
база, база данных, бд - собственно хранимая информация.
система управления базами данных, субд - ПО предоставляющее доступ и инструментарий для работы с БД
2Zolter:
Quote
Quote
…skipped…
высказывание чушь.
от корки до корки, досканально все тонкости знать естественно нереально. я лишь высказался что я работал со всеми типами базы и как оптимизировать каждую из них я в курсе. …skipped…
если мне закажут оптимизировать проект на постгресе или оракле - я отказыватся не буду в отличии от вас …skipped…
Со всеми типами субд? Т.е. вы настолько свободно владете оракловым pl/sql, transact-sql субейза, xquery и т.д и т.п.?
Если Вам закажут оптимизировать проект на незнакомой Вам субд… И Вы возьметесь и не проблема, что заказчиков Вы скорее всего обманете, так как заказчику обыно нужно в реальные сроки, за реальные деньги получить реальные результаты, а Вы им предоставите услугу - я обучусь за Ваш счет и не факт, что стану гуру, но что-нибудь Вам сделаю… Интересные у Вас заказчики… или Ваше отношение к заказчикам… А у Вас не было ситуаций, когда заказчик попадается толковый и Вы работаете бесплатно, ибо по условиям догвора не уложились в сроки и доделываете за свой счет и в свое свободное время?
Quote
А как Вы определяете, что выполнили работу на уровне выше среднего?
Quote
И часто заказчик предлагает Вам технологии с помощью которых необходимо решать задачу? нагрузки и требования к функционалу… ох и ох… опять двадцать пять… т.е. подход такой - нагрузки большие, функционала требуется много - оракл, если нет - мускул… и не важно, что криво спроектированная БД в оракле, потому что не умеете вы ее правильно проектировать, будет тормознее, нестабильнее и сложнее в поддержке, чем то же самое, но спроектированное в системе которую вы досконально знаете и при возникновении ошибки ora-600 знаете, что делать и куда бежать, а не накрываете голову подорожником и сутками напролет рыскаете по интернету в поисках решения…
Quote
невнимательно прочитали вы мой пост - там вся соль была в последней фразе
Quote
это про нагрузку на БД - для БД нагрузка не важна, главное, чтобы для СУБД было достаточно ресурсов. А по поводу организаций - прошло, для меня по крайней мере, то время когда сервера в организациях собирали по принципу - поставим 486, на него freebsd и летать будет, даже если мы на него почтовый сервер повесим и сайт корпоративный…
да не спорю я, не спорю - предлагать клиенту решение на заведомо менее производительной системе - увеличивать бюджет проекта по оборудованию, но если считать еще дальнейшую поддержку и прочее…, одним словом не уверен, что при внедрении и дальнейшем сопровождении проекта на малознакомой для Вас, как для саппорта, платформе для клиента совокупная стоимость владения будет меньше. Равно как и у Вас головняков. Хотя, если клиент готов оплачивать Ваш профессиональный рост по данной платформе - ну что-ж бога ради…
Quote
Не спорю постгре действительно производительней. А про финансовые ресурсы компании я уже писал. Равно как и про эффективность выполнения запросов на знакомой и незнакомой СУБД.
Я собственно с самого начала говорил - не стоит утверждать, что мускул не в состоянии справиться с подавляющим большинством веб-проектов, главное - это наличие знаний в голове и умение эти знания применять на практике. И не спорю я про то, что в некоторых случаях удобнее применять другие СУБД, примеры тому есть в моих предыдущих постах. Но я категорически против необоснованных высказываний - хотите, чтобы было хорошо - идите стройными рядами туда, потому что здесь вам не тут. Тем более, если есть достойные примеры реализации крупных (а иногда и аналогичных) проектов на охаиваемой технологии.
Quote
любой мужчина - ребенок, просто с возрастом меняются цены на игрушки (С) не помню чей
Quote
Quote
…skipped…
винды
ну терабайт и что? ах да, я понимаю, тем кто всю жизнь отработал на мускула таких величин не знать. да портал пишиться на yii, представьте себе не все сторониики писать мега порталы на чистом php что бы получить 10%-ю прибавку в производительности.
да ладно, и на мускуле можно сделать таблице из блобов и хранить в них хоть ежедневный полный бэкап почтового сервера майкрософт. Дело не в этом. Просто, стоял я рядом с проектом полностью написанном на оракле - кадастровая гис система по области, там БД к гигабайту добралась только через 6 лет работы, и тоговая система так же на оракле, 3 года работы ~40 магазинов и нету терабайта даже близко…
а по поводу проекта на yii - опять же как и с выбором БД - все дело в том какие у вас уговоры с заказчиком по поводу внедрения и поддержки… если сделал и забыл - тогда все понятно, а если сделал и поддерживаешь - то, либо yii хедлайнер для вас на следующие несколько лет и вы готовы к тому, что по мере доработок текущей ветки вы будете дорабатывать (уже после сдачи) проект, даже в случае прекращения разработки самого фреймворка… Либо вы работаете по принципу - налепил заплаток, сдал и забыл…
что значит подойдет? естественно всё что угодно можно реализовать практически на чем угодно. суть не в том можно написать или нельзя, суть в том рационально это будет или нет.
согласен. про рациональность мысль здравая
представляете я могу позволить себе выделить время что бы почитать каждый вечер чтото по субд или по программированию на интерисующем меня языке. а мысл тогда быть программистом?
…skipped…
не обязательно учить всё досканально, достаточно просто учить. а досканальные знаний к вам прийдут когда вы уже действительно будете использовать технологию в практике. знания лучше усваиваются именно в момент работы.
Друг мой, почитать и изучить, все-таки, несколько разные вещи…
Это как экзамен по информатике и программированию - вроде и то и то из одной области, а результаты разные… теоретические знания это хорошо и без них никуда… но специалистом становятся только после массы времени проведенной в попытках применить теоретические знания на практике… если вспомнить детство - Вы ходить учились как минимум полгода, а говорить и того дольше, а сейчас Вы применяете эти знания не задумываясь почему - потому что десятки лет практикуетесь не переставая… и Вы считаете - прочитал книжку, две недели посидел, попрограммировал, и стал специалистом настолько, что коммерческий проект готов реализовать и поддерживать?
опять таки неверно. это смотря с какой стороны смотреть. если смотреть с той стороны что вы сидите на месте и изучаете только php/mysql - тогда как раз таки в ширь развиваетесь вы, потому что не двигаетесь в перед а зависли на одной позиции.
Видите ли в чем суть - когда-то в эпоху sinclair zx spectrum, из сильной ограниченности ресурсов этого компьютера, люди стремились писать именно совершенный код - каждая программа была как произведение исскуства. помнится сам потратил кучу времени на изучение недокументированных возможностей процессора, чтобы научиться перерисовываь экран за одно прерывание… но были и проекты в которых людям не важна была отточенность и производительность и они говорили - либо так будет работать, либо это не на синклере надо решать - вот это как раз ваш подход. незачем изучать досконально, достаточно по верхам и пойдет, зато я могу и тут и тут, но считать себя специалистом в обеих областях наверное излишне…
а я предлагаю как раз таки развиваться вверх, двигаясь к новым технологиям. знания по своему основному языку надо безусловно постоянно улучшать но плюс к этому надо двигаться в сторону нового и познавать новые технологии. не надо останавливаться на одном месте, ведь не зря в мире каждый месяц выходит просто куча всего нового что чем то удобнее или быстрее прежнего.
никто и не спорит - нельзя стоять на месте… но если мы говорим о саморазвитии это одно, а если мы говорим о коммерческой составляющей вашей деятельности - это совсем другое… посмотрите вокруг, много организаций (не мелких фирм, которым что с автоматизацией, что без оной - все едино) постоянно меняют технологические платформы на более новые? да вы сами, сдав проект на yii 1.0, будете переделывать его на 1.1, или пока не наступит следующий виток развития продукта будете только поддерживать?
Представляете жизнь меня сталкнула с такими вещами как бэйсик и мне пришлось участвовать в МАН-е за наш город когда мне было 10 лет. так что мне теперь повешаться что я не доконца изучив бейсик занял второе место в городе? о, Боже, прости меня за то что я маленьким пошёл на перекос веб программированию.
всегда уважал людей с развитым чувством юмора
мне не обязательно знать досканально perl что бы знать для чего его рациональнее применять чем php. поэтому когда я сталкнуть с тем что на php мне надо будет разработать к примеру джабер клиент - я уже буду знать что рациональнее это будет сделать на perl-е, не потомучто я буду его супер знать, а потомучто я знаю его особенности и его плюсы. а вот когда мне надо будет на перле его написать - вот тогда я и начну досканально его изучать.
если уж вам необходимо будет разработать джаббер-клиент, то что мешает вам разработать его на php? по сути, что perl, что php, в данном контексте, оба являются интрпретируемыми - не вижу причин почему не разработать джаббер-клиента на php. а уж если вы плюнете на интерпретаторы и пойдете к компилируемым языкам, поверьте лучше уж и не браться писать джаббер-клиента, а поискать существующий. Ибо пока вы его напишете качественно - можно создать 5 (если не 25) веб-проектов и получить куда большие деньги, чем за тот же джаббер клиент…
to be continued…
Quote
Был такой анекдот:
на улице сидит молодой гитарист, играет на гитаре сольную партию, пальцы по грифу бегают с такой скоростью, что их практически не видно и использует кучу разных техник… народ проходит мимо, останавливается, улыбается идет дальше…
За углом сидит пожилой гитарист и нежно, плавно и очень медленно дергает одну и ту же струну, зажав ее на одном ладу…
люди проходят, останавливаются и долго стоят и слушают…
в конце концов один человек подходит к старому и говорит - слушай, ну я не понимаю - вон парень глянь как старается, сколько нот в секунду он успевает перебрать, а ты только одну, почему люди возде тебя стоят…
на что старый отвечает… я уже нашел главную ноту в своей жини, а он еще нет…
Quote
согласен, изучать надо много, но вот доказывать, что какая-то технология отстой, потому что, как вам кажется, она малоприменима в каких-то условиях действительно не стоит…
2tyvon:
Это высказывание имело целью показать не то, что мускул готов обслужить такое количество пользователей на таком железе, а то, что нагрузка на СУБД понятие весьма относительное…
2sergey kuznetsov:
По поводу иронии и yii…
Честно говоря всегда с подозрением отношусь к коммерческим проектам реализованным на платформе которая очень молода. Опять же, видимо опыт печальный во мне говорит
Приведу конкретный пример - в одной организации был внедрен проект разрабатываемый опен-сорс, на самой заре его существования, когда разработка шла полным ходом. А потом вдруг разработка взяла и прекратилась, но проект уже в работе, баги продолжают выползать - на них лепятся заплатки… и тут оказывается, что есть аналогичный проект который разрабатывается полных ходом. Внедряется он и история повторяется только с тем успехом, что еще и единственный человек в компании который это вел увольняется - берут нового, а тот говорит - ребята, все круто, но я не буду это поддерживать - потому как тут все криво, но либо переделывать полностью, либо вообще другое решение внедрять… а теперь ставим себя на место руководства организации…
ух… вот это написал, 3 раза чай попить успел
давайте не ссориться, но обижать мускула не дам 
сори но я стока читать небуду )
я уже в принципе во всем высказался ))
п.с. Sergei Kuznecov, и кто теперь из нас двоих (я и dikoy) обладает юн. максимализмом? 
я наверное, только это уже старческий маразм
Таки прочитал)
Ну теперь вы хоть немного объективнее смотрите на вещи, а не считаете что мускул лучшее решение для любых проблем
да я и раньше не считал мускул панацеей, но уж больно обидно было за него - взяли и сразу в кювет
хм… но я то знаю, что внутри всех субд на самом деле движок мускула, а все остальные навороты сверху - это чтобы никто не догадался, что есть только одна субд - мускул
2 zolter
база на терабайт в городской недвижке? это чего за данные, если не секрет? : )
скорее всего в основном BINARY (фото / видео) - тогда и мускул справится, но лучше уж в файловой системе такой объем BINARY хранить…
P.S. никогда не понимал зачем бизнес-логику выносить в базу данных (писать хранимые процедуры в бд)
Quote
скорее всего в основном BINARY (фото / видео) - тогда и мускул справится, но лучше уж в файловой системе такой объем BINARY хранить…
терика конечно еще не набралось, но такую задачу поставил перед нами заказчика прогназируя что будут такие объемы данных. сейчас примерно >250гб. да, там куча фото, видео и прочего хлама (карты, недв. обьекты и тп). было принято решение хранить в базе по многим внутренним заморочкам.
Quote
иногда приходиться над результатом одного запроса к примеру проводить каикето действия, потом над его результатом еще какието действия и над третим результатом тоже действий уже перед тем как отдать пользователю. для этих целей многие используют пхп что весьма неверно со стороны оптимизации. в данном случае всё на себя берет хранимая процедура которая выполняется на сервере что значительно увеличивают саму скорость таких манипуляций.
Quote
не буду говорить об оптимизации - тут даже сказать нечего - итак ясно нету ее
но пункт второй, вы ведь наверняка задумывались о плане резервного копирования БД? и какие ресурсы планируется выделить под резервное копирование?
вопрос третий - какова предварительная оценка дублирующихся бинарных данных?
вопрос 4ый, а в случае обвала БД и отсутствия адекватной резервной копии представляете как бинари в базе ремонтировать?
честно говоря, я бы наверное, не решился на такой, вне всякого сомнения, рискованный шаг…
Quote
Quote
иногда приходиться над результатом одного запроса к примеру проводить какие-то действия, потом над его результатом еще какието действия и над третим результатом тоже действий уже перед тем как отдать пользователю. для этих целей многие используют пхп что весьма неверно со стороны оптимизации. в данном случае всё на себя берет хранимая процедура которая выполняется на сервере что значительно увеличивают саму скорость таких манипуляций.
Zolter прав - в контексте программирования мелких и средних веб-сайтов очень часто встречается метод ускорения обработки результатов запросов путем испонения кода обработки самой СУБД - поскольку, как ни смотрите, а СУБД в любом случае обработает набор данных быстрее чем внешнее приложение или скрипт.
Кроме того, есть еще технология построения multi-tier (многозвенных) приложений, в которых бизнес-логика сознательно выносится на специально-выделенный сервер (т.н. сервер приложений) задача которого быть прослойкой между фронт-эндом и выделенным сервером БД (ну или другим сервером приложений). Так вот вынос функционала в те же хранимые процедуры является частным случаем построения многозвенки
Хотя, если присмотреться, любое веб-приложение уже как минимум трехзвенка Браузер - пхп (ну или еще там чего) - БД
цели разделения приложения на много уровней могут быть разными - например, простейшие:
мультиплатформенный фронт-энд (имеется ввиду десктопное приложение) - зачем под каждую платформу переписывать специфические куски обработки бизнес-логики - достаточно написать кроссплатформенный UI и унифицированный обмен данными - (можно сравнить с браузер+ajax+json) - такое приложение очень легко портировать на другие платформы.
обработка на сервере больших наборов данных - клиент заведомо более медленная машина.
обработка данных независимо от действий конечного пользователя.
и т.д.
to dikoy
не надо тут рассказывать что там нету оптимизации если вы не видели её структуру и незнаете задач которые стоят перед исполнителями. под базу выделено два сервера которые на связке работаю друг с другом при этом данные зеркаляться каждые N суток на серверах что б в случае выхода одного из серверов - второй держал на себе сайт. дублирующиеся данные чистят специально нанятые для этого операторы, хотя естественно процент таких данных есть, и немалый. просто задач перед проектом большое множество в том числе очень частая обработка изображений, видео и тп в живую несколькими пользователями. при таких требованиях работа с базой имеет больший плюс по скорости и удобству. хочу заметить что выборки по базе идут достаточно быстро несмотря на объемы данных в ней.
сорри сразу не уточнил - в данном случае под оптимизацией я понимал оптимизацию всего проекта. статика (ваши бинари) + ngnix по сравнению с вычиткой из базы помноженное на количество одновременных пользователей… думаю понятно (даже кеширование запросов не сильно поможет). тут структура БД не при чем.
данные зеркалятся каждые n суток - а в промежутке падение сервера Вас не страшит - стройте кластер тогда уж. кстати 1 ТБ на работающей системе у вас будет по сети (1Gb) синхронизироваться пару суток, если не больше. При условии, что сервера у вас связаны-таки гигабитной сетью.
Дублирующиеся данные чистят специально нанятые люди, за которыми повторно чистят еще специально нанятые люди, работу которых контроллируют… знаем, проходили - надо этот процесс автоматизировать - не то, чтобы сильно сложная задача, и, чтобы процесс поиска одинаковых бинарников не занимал недопустимо много времени необходимо считать хеши каждого бинаря, которые так же хранить в БД, и сравнивать по ним - тогда опять-таки не понятно зачем бинари хранить в БД - в чем выгода?
одновременная работа с одним и тем же графическим файлом? а не поясните - как вы собираетесь применять внесенные изменения к графическому файлу при параллельной обработке?
Если не сложно - хотелось бы понять чем действительно хранение бинарей в БД отличается от хранения на диске?
Не обижайтесь, возможно, я не до конца понимаю Ваши задачи, но пока мне видится очень сырой предпроект и, есть такое понятие, "мертворожденный" проект.
забьем долго описывать все тонкости.
Товарищи, по-моему вы слишком разошлись по теме… не стоит сравнивать возможности оракла, postgresql и моськи… базы разные совершенно и годятся под разные задачи. моська - это самое простое и с тем же самое часто использумое. оракл - это промышленная база, на нем строят крупные проекты, где нужна гибкость, стабильность, защита и бизнес логика на базе. к сожалению с postgresql не работал, но думаю тут тоже есть области применения… Спорить что лучше можно до посинения, но для каждого проекта база должна определяться в момент проектирования и это не обязательно моська
меня же интересовал вопрос о innodb и myisam в моське.
верно.
хватит флуд разводить