Какую выбрать БД?
 

Не могу решить какая лучше подойдет БД NoSql или Sql

ЗАдача для которой это нужно:
Нода парсит сайт и отдает данные при запросе мобильному приложению. (все просто)

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

Так какая БД подойдет лучше?

postgresql в тренде... вы че все на мобильные приложения подсели, конкуренты)

Memcached, Redis? ХЗ, по-моему, подойдет любая key-value.

Неа, разная аудитория)

Не совсем понял про эту штуку, если упадет приложение данные всеравно остануться в ОЗУ?

И кто может обьяснить что такое "Атомарные операции" с примером если не тяжело)
А то не фига не понятно

Приложение упадет, memcached останется. )
Тут я лоханулся, memcached не умеет дампиться на диск без костылей. Редис это умеет из коробки: http://redis.io/topics/persistence.

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

ixth, спасибо

Даже не знаю что за пример ты хочешь?!

Вкратце: Из-за того, что к базе имеют одновременный доступ несколько клиентов могут возникать "строки призраки". Другими словами Один клиент удалил строку, а другой пытается в нее записать данные. Нарушается целостность базы данных.

Это то, что я про mysql читал. У меня подобной ситуации не встречалось в практике, но говорят бывает на MyIsam, для того, чтобы подобного небыло либо юзать блокировки таблиц, либо innodb тип таблицы.

http://www.nestor.minsk.by/kg/2003/50/kg35010.html

Если сервер на ноде чем не устраивает данные в var ?
Как я понял изменение данных довольно редкая и не накладная задача?
Основной вопрос это быстрый доступ к данным множества клиентов?

Имхо данные записываются в любую удобную БД после этого присваиваются любой var переменной где с успехом и хранятся на любой запрос от клиентов данные отдаются максимально быстро и без лишних танцев с бубном.

Единственное возможное проблемное место это целостность данных при внезапно остановке ноды но целостность легко обеспечить просто сохранив данные перед использованием(присвоение� � переменной) сохранение загрузка данных элементарна имхо все должно неплохо работать прямо из коробки и не нужно хитрых решений.

MallSerg, Данные будут весеть в ОЗУ и так просто что бы если что то дропнет или какае то другая проблема, не парсить данные заново потому что парсить там приилично, то данные будут браться из бд

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

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

А если совсем по хорошему то сначала пишутся тесты которые тестируют приложение по ТЗ а на основе этих тестов пишется приложение.

Это пока для меня слишком

Я бы сделал так: SQL, если отношения есть (или будут), и NoSQL, если их нет (и не будет).

Redis заменяется на любое другое - он для кеша

Моё имхо, пытаться делать реляции на NoSQL - это просто жесть

melky, что подразумеваеться под "отношение между сущностями" ?

на которой умею и которую знаю.

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

(my)sql стопудово более гибкий вариант. По сути я еще не сталкивался с задачами где, требовалась иная бд. С другой стороны нужны потребности, чтобы выбрать нужный вариант.

Короче: Реляционная база данных vs NoSQL

Выбери то, что тебе нужно, а не то, что посоветуют!

Я вот и пытаюсь понять что мне нужно)

я лишь предлагаю варианты. ничего не навязываю :)

отношения - это связи между таблицами вида "один-к-одному" , "один-ко-многим" и "многие-ко-многим"

лично для меня геморно было разруливать их на NoSQL. в (my)SQL это делают JOIN запросы, но с ними ... легче как-то, что-ли

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

тут уже оофтоп пошел )

есть CRON - тут для расписания вещь более подходит, мне кажется

Блин, это я тему перепутал, убрал куда хотел изначально http://javascript.ru/forum/showthread.php?p=326433

Короче перед тем как создавать тему нужно было до конца разобраться чем реляционные бд отличаються от noSql

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

ключ-значение: reddis
семейства столбцов: casandra
документо-ориентированные: mongoDB
графовые: Neo4J
и т.д.

Рекомендую к прочтению М. Фаулер NoSQL - это небольшая книженция в которой коротко и без воды рассмастриваются все основные виды NoSQL СУБД.

На лицо суждение о NoSQL по СУБД типа ключ-значение, но NoSQL этим не ограничивается (читай пост выше).

Для сложных отношений нет ничего лучше графовых СУБД типа Neo4J (а это NoSQL). Например запрос типа: построй карту "6-ти рукопожатий" от юзера А до юзера Б в графовых СУБД делается очень просто и очень быстро, а во всех остальных решениях это как правило ад.

Очень сомнительная иллюстрация.

Зачем монге ещё редис вешать? Как и любая нормальная СУБД монга старается держать всё в оперативе и при нормальном индексе кеш редиса не даст никакого профита. Также Redis (или тот же memcacheDB) можно спокойно юзать как самостоятельную СУБД

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

Более того, в современном мире в рамках проекта используется как правило 2-3 СУБД одновременно, даже есть термин - многовариантная персистентность.

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

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

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

Использование решений "из-коробки" вроде MongoDB (на самом деле много кто предоставляет автосегментацию, но как правило это дорогие решения вроде Oracle) может переложить эту заботу на другие плечи.

PS: что касается Postgre, то у него есть своя отдельная СУБД для проектирования таких вещей.

Вот тут главное правильно оценить ситуацию:
1. Приложение может и не вырасти.
2. Написанный код (выбранный способ) может и не справиться с объемом, т.к. ситуация по сути абстрактная
3. Затраты на написание сегм. кода больше.

Иногда проще написать с нуля, чем сразу писать то, что не понимаешь.

Все зависит от скорости роста (проекта, посещаемости). Иногда проще взять машину помощнее или памяти побольше и проблема будет решена, нежели сразу писать код|выбирать способ рассчитанный на высокую нагрузку. Конечно в идеале лучше сразу писать код, выбирать базу рассчитывая на нагрузку. Особенно если это не затратно как по времени написания, так и по деньгам аренды оборудования.

Но как показывает практика, если что-то делаешь впервые, то лучше делать это проще.

Проект может не взлететь. Писать дольше на том, что изучаешь. Основная ошибка будет не там где думаешь. Это от того, что кибер понятия не имеет с чем столкнулся и выводы, уверен на 80% сделает в большинстве своем ошибочные, даже если ты ему все правильно скажешь. Прежде чем он сделает правильные выводы у него должен появиться опыт.

Поэтому чё париться предлагать писать сразу мега нагруженное приложение, когда ты даже тз его не знаешь, темы, идеи и посещаемости, а также динамики роста?

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

Можно пример в соответствии с этой темой. Т.к. я совсем не понимаю о чем ты.

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

Вот ты все свою линию гнешь. А я бы посоветовал взять vps, а потом добавить ядер, памяти или диска.

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

Я же писал: некоторые СУБД умеет из коробки сами сегментировать данные, т.е. просто настраивается ключ сегментации для каждой коллекции / таблички и СУБД сама всё сделает включая равномерное динамическое размазывание неиспользуемых данных.

Например: MongoDB, PostgreXL (бесплатные),
Oracle, MS SQL Server (платные).

Я например юзаю облачный сервис MongoLab поверх MS Azure и сейчас плачу около 20 долларов в месяц.

***

Писать самому сегментацию геморой, т.к. для каждой СУБД могут быть свои паттерны и стратегии, например для реалиционок - это:

1) Динамическое порождение таблиц (т.е. деление на споты);
2) Балансировщик - маршрутизатор;
3) Логика динамического размазывания неиспользуемых данных по нодам;
4) Слой сверхбыстрого доступа.

И т.д. Примерная кодовая часть ~ 10-15k строк кода на языке типа JS.

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

К сожалению, так и будет :)

спалил контору :)

спасибо, не знал.

придётся переосмысливать свою думалку на графы - с наскока вряд ли получится представить все данные в виде графов

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

Обычно графовые СУБД используются как вспомогательные, например, граф отношений (при проектировании той же ленты новостей с графом всё становится тривиально) в соц сетях или "возможно вас заинтересует" в магазинах. Городить всю систему на графах будет не оптимально.

Спасибо, Завтра прочитаю думаю)