резнесение базы на несколько серверов

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

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

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

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


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

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

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

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

Я не совсем по этому поводу согласен, так как нагруженность проекта понятие относительное, для кого - то и 10 тыс уников в день это большая нагрузка, а для кого это обычная ситуация....
Еще раз повторюсь что можно писать морду и на пыхе, а когда вот пыха станет "узким горлышком" вот тогда и можно уже подумать о переходе на другой яп.
А насчет бд то есть много open source проектов которые могут горизонтально расширяться без костылей, можно и mysql расширять но с костылем, используете пока привычный вам mysql а как придет время для серьезного расширения, то тут уже будите думать, самостоятельно заниматься расширением, или же пересесть на другую бд, которая это умеет из коробки...
Просто в mysql не должно быть логики, триггеров, и поменьше join запросов.
И вам мой совет, решайте проблемы по мере их поступления...

-----
Так было, так есть и так будет

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

а оплачивать переписывание кто будет? Особенно если проект уже запущен в работу, что добавляет головняка не только с переисыванием а переносом данных клиентов.
. Поэтому и остается в системмах котрые неожиданно для себя выросли из коротких штанишек, PHP/Mysql с кучей костылей в виде node.js всяких там мемкешей акселераторов и прочего.
Если системма планируется на высокую нагрузко изначально (другой вопрос что 99.9% этих наполеоновских планов так и остаются мечтами, особенно если ха это берутся новички а не серьезные фирмы с многолетним опытом разработаки) выбирать заведомо проиграшный вариант только потому что проще синтаксис и настройка - глупо.


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

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Дело все в том что нагрузка при которой узким местом может быть яп, очень редки, так что не стоит сразу писать на с++ или на java если на 100% не уверен что это того стоит, так как только усложнишь себе жизнь, писав на них год, когда на том же пыхе это можно сделать за 2-3 месяца.

Для большинства задач, транзакции и вовсе там не нужны, так как у них другие модели данных и совсем по другому хранишь данные нежели в рсубд, но ради примера в redis есть поддержка транзакции.
Да я не говорю что nosql это серебряная пуля, для такие задачи с транзакциями в большинстве своем не применимы.
Но если так подумать то они, для обычного веб приложения и не нужны...
А если есть интерес к это теме, то есть даже теореме насчет бд, насчет расширяемости, доступности и согласованности, не помню как она называется, но если погуглить можно найти, так сказать для каждой бд свои задачи которые она должна решать...
(Добавление)
И думаю достаточно было сказано, а то уж прям какой - то холивар на тему бд начинается...

-----
Так было, так есть и так будет

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

имхо второе выгодней (хотя цифр у меня в руках нет)

(Отредактировано автором: 26 Февраля, 2013 - 12:02:25)

Разумеется. Пробьлемма в том что каждый второй новичек обычно на 100500% уверены что он второй Цукерман.


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


если речь о чисто страничках то да. Но если речь о всем комплексе решений то не факт.


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

Это называется ACID и есть ряд исследований в который математически доказывается что NoSQL системмы это не могут обеспечить в принципе.



это не транзакции - там даже нормальных блокировок нет.



разумеется, только ищут обычно не БД для решения конкретной задачи а делают задачу и кнопят туда ту БД которую знвют.
Фишка в том что реляционные субд могут заменить NoSQL а наоборот - врядли. А не каждый готов платить за сопровождение двух СУБД в одном проекте.
Не далее как в прошлом году, по этой причине, пришлось на одном проекте перекладывать проект с CouchDB на MSSQL.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Насколько я знаю ни одна бд не может обеспечить все 3 функции, максимум тока 2 какие-либо...И nosql системы тут не причем...

Каждая операция - атамарна, есть возможно несколько запросов применить как 1 атомарную операцию...

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

А вот про это можно поподробнее, зачем и почему?

-----
Так было, так есть и так будет

игра+примочки социалки

вообще то четыре и реляционные СУБД это обеспечивают при соответствующих настройках хоть и за счет некотрой потери производительности.


еще раз - там нет нормальных блокировок и уровней изоляции транзакций. Транзакция на одного пользователя никому не нужна.


обычно волпрос тоит наоборот - зачем мне две разные субд если может справится и одна. А для кеширования ключ-значение и мемкеш сойдет.


и мнго ты знвешь системм где данные можно терять. Например этот форум. От потери данных конечно никто деньги не потеряет, но вряд ли кто то обрадуется если потеряются его посты или аккаунт.
Ведь не зря в последних версиях mysql по дефолту теперь не myisam а innodb


амерский заказчик заказал кким то румыноам сайт по логистике контейнеров. они увидевши что все базируется на ордерах, накладных и прочем влепили документно-ориентированную БД. Потом не знаю какие там прблеммы возникли (скорее всего с поиском, складским учетом и генерацией многочисленных репортов.), но опустившись на землю начали часть данных перекладывть на mssql. потом заказчику это надоело он послал предыдущую команду куда подальше. В принципе часть данных типа языковые метки для интернационализации и т.д. удобнее было хранить в CouchDb и получать в виде Json но поскольку мне светил саппорт, доработка и особенно апдейты этого хозяйства я решил не иметь лишного гемора и все свел в одну БД.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Значит не эта теорема, короче вот http://ru[dot]wikipedia[dot]org/wiki/%D0[dot][dot][dot]%D0%BC%D0%B0_CAP

Все правильно с рсубд можно сделать почти все, а потом в мем кеше кешировать, но
как ранее говорилось для своих задач своя бд, например вот общение в реальном времени, для таких дел mysql + memcached использовать с моей точки зрения не разумно, это один из примеров где рсубд не лучшее решение.

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

-----
Так было, так есть и так будет

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


Законы Мерфи тебе возразят - потеряются не старые топики а самые новые вместе с аккаунтами тех кто их повтыкал.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore