LINUX.ORG.RU
решено Форум — Development  

[SQL][NoSQL]Как лучше всего хранить френдов?

 ,


0

1

Описание
Есть десять миллион юзеров. Есть система френдирования(как в ЖЖ). Т.е. оно не обязательно взаимное. (вон у Тёмы 24 френда, а Тёма во френдах у 58962-графоманов/ботов...)

Задача
Как лучше хранить информацию о взаимоотношениях пользователей?
(никакой другой информации(постов, дат рождения...) нет)

в голову приходит лишь SQL: 

uid   friendid
1     2
2     1
2     2
2     3
3     2
...

Собственно правильно ли так делать?
Или для этой цели больше подходит какой-нибудь NoSQL? (особенно интересует CouchDB)

← climm антиспам
Есть ли «честный» аналог функции strtod? →

С реляционной точки зрения правильно. SQL СУБД или что-то другое использовать для реализации это уже не вопрос о правильности. Если SQL'ная база юудет устраивать по производительности, то нечего искать альтернативы.

mashina ★★★★★
()
Ответ на: комментарий от mashina

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

anonymous
()

> Или для этой цели больше подходит какой-нибудь NoSQL

NoSQL про другое. В данном случае его никоим образом сюда впихивать не стоит.

Ну и отношение многие-многим (дружба) вы правильно изобразили, так и хранить, только правильно натравить индексы и все будет хорошо.

anonymous
()
Ответ на: комментарий от anonymous

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

mashina ★★★★★
()

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

VladimirMalyk ★★★★★
()
Ответ на: комментарий от Donnie_Darko

«Производительное решение» - весьма странная сущность. Для высоких нагрузок акутальнее честное горизонтальное масштабирование. Короче когда начинаешь резать таблички на шарды, то все удобности РСУБД начинают только мешать, тут уж лучше браться за NoSQL. Если шардить не собираешся, сиди на своей РСУБД.

dizza ★★★★★
()

теги: [стартапчик], [социальная сеточка], [клон вконтактика]

по теме: используй AllegroCache и забудь реляционные костыли, как страшный сон. Нереляционные (NoSQL) тоже забудь. За технологиями Allegro будущее, это технологии Web 3.0

anonymous
()
Ответ на: комментарий от anonymous

>теги: [стартапчик], [социальная сеточка], [клон вконтактика]

НЕТ!
для себя делаю проект, точнее учусь делать проекты, работать с БД, проектировать, etc...

Donnie_Darko
() автор топика
Ответ на: комментарий от Donnie_Darko

>для себя делаю проект, точнее учусь делать проекты, работать с БД,
проектировать, etc...

Есть десять миллион юзеров.


По-моему, это юношеский максимализм. Но, да, если такая неуверенность в том, что знаний SQL/РСУБД Вам не хватит. то используйте NoSQL, AllegroCache и CouchDB - нужной дорогой идете, как говорится...

yaws ★
()

мжет для такого «простого» случая подойдёт берклиДБ?

yyk ★★★★★
()
Ответ на: комментарий от yaws

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

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

все это just for lulz и не несет $стартап$-цели...

Donnie_Darko
() автор топика
Ответ на: комментарий от Donnie_Darko

>c NoSQL почти не знаком еще

где-то на лоре видел как хвалили mongodb - человек писал что вздохнул с облегчением после того как пересел на него после 10(!) - летнего опыта с *SQL

Donnie_Darko
() автор топика
Ответ на: комментарий от Donnie_Darko

Лучше реляционной СУБД такую структуру никто хранить не будет. У No-SQL решений практически нулевые возможности анализа данных.

anonymous
()
Ответ на: комментарий от Donnie_Darko

Почитайте достаточно длинный срач на РСДН - там мнения, ящитаю, несколько поавторитетнее будут нежели тутошние:
http://rsdn.ru/forum/philosophy/4063420.all.aspx

Достаточно познавательно, и. по-моему, слив носклистов защитан :)
(хуле - http://wordpress.kendaric.net/wp-content/uploads/geekandpoke-nosql.jpg)

yaws ★
()
Ответ на: комментарий от anonymous

> это технологии Web 3.0

Web 3.0? Как вы себе это представляете? И почему потребности Web 3.0 в системах хранения данных так отличаются от потребностей предыдущих поколений?

amomymous ★★★
()
Ответ на: комментарий от Donnie_Darko

>а где/когда стоит непременно использовать NoSQL?

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

Например, в интернет-магазине с огромной кучей совершенно разных групп товаров, у которых мало общих свойств. В таком случае на РСУБД делать EAV, а оно часто превращается в большой костыль.

Но даже в этой ситуации вполне можно использовать РСУБД.

anonymous
()
Ответ на: комментарий от Donnie_Darko

> а где/когда стоит непременно использовать NoSQL?

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

Можно конечно и на реляционке такое слабать, но на носкуле будет намного проще и быстрее.

Vit ★★★★★
()
Ответ на: комментарий от Donnie_Darko

а где/когда стоит непременно использовать NoSQL?

Раз уж тут флейм развёлся неправильный, отвечу: по возможности, никогда.

Это непростой вопрос, наматаешься с РСУБД, почитаешь множество статей на эту тему (т.е. SQL vs всё остальное), ознакомишься с реляционной теорией (советую К. Дж. Дейта почитать) тогда будешь иметь предствления о выборе между РСУБД и NoSQL.

anonymous
()
Ответ на: комментарий от Vit

> Там где не получится жестко задать свойства объектов. Например, в каталоге товаров. Книжки и пылесосы имеют разный набор атрибутов.

Можно об этом поподробнее? Разве NoSQL - это не «key-value» в подавляющем числе случаев? Какая конкретно NoSQL DB здесь может помочь, их ведь десятки?

Предыдущего анонимуса, упомянувшего EAV, тоже прошу присоединиться. Можно ли где-нибудь на практике увидеть реализацию «слабоструктурированной схемы» (вроде это так называется) при помощи NoSQL? Спасибо!

anonymous
()

я бы взял обычное nosql решение с двумя типами хранения

1) мои друзья - hash [idдруга] 2) я в друзьях - hash [idдруга]

самое быстрое решение.

Deleted
()
Ответ на: комментарий от anonymous

>Можно об этом поподробнее? Разве NoSQL - это не «key-value» в подавляющем числе случаев?

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

Какая конкретно NoSQL DB здесь может помочь, их ведь десятки?

Вот тебе сходу пример из документации couchDB, на питоне.

[code=python]# select database db = couch['mydb']

#create a document and insert it into the db: doc = {'foo': 'bar'} db.save(doc) [/code]

http://wiki.apache.org/couchdb/Getting_started_with_Python

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

anonymous
()
Ответ на: комментарий от amomymous

> Web 3.0? Как вы себе это представляете?

Читайте: http://franz.com/

И почему потребности Web 3.0 в системах хранения данных так отличаются от потребностей предыдущих поколений?


Потому что объёмы информации, количество информационных атомов и связей между ними растут экспоненциально. То же касается информационных потоков. Никакие системы «предыдущих поколений» (читай - императивные языки + реляционные СУБД) не проектировались с расчётом на подобные объёмы и скорости. В результате чего в контексте современных информационных реалий терпят стабильное фиаско.

Franz же спроектировали всё from the ground up, используя на 100% потенциал старейшей и в то же время перспективнейшей мультипарадигменной языковой метасреды - Common Lisp.

anonymous
()
Ответ на: комментарий от anonymous

> Какая конкретно NoSQL DB здесь может помочь, их ведь десятки?

Популярных не так уж и много. mongoDB есть смысл посмотреть.

Vit ★★★★★
()

Для хранения френдов (да и вообще каких либо отношений) можно использовать FlockDB. Ее как бы твиттер для себя разработал и использует.

cyberface
()

спасибо за ответы, отложил в долгий ящик nosql

Donnie_Darko
() автор топика
Ответ на: комментарий от anonymous

С удовольствием посмотрю на сайт, как только поднимется.

А что вы скажете об облачных технологиях, где вроде как успешно применяются и реляционные СУБД, и императивные языки, и вроде как нет проблем с масштабированием?

amomymous ★★★
()
Ответ на: комментарий от Donnie_Darko

У тебя четкая система отношений, для этого как раз созданы RDBMS. NoSQL нужны для schema-less документов, key-value сторы. Не обязательно все данные проекта засовывать в одно хранилище, можно использовать несколько разных.

tensai_cirno ★★★★★
()

>Как лучше всего хранить френдов?

Описание
Есть десять миллион юзеров...

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

anonymous
()

а тебе для чего френды нужны, т.е. запросы к сей табличке ты будешь как делать? выбирать чаще друзей и по uid или uid по friendid. Опятьже зависит от типа ключей. И воще тут тупой посиск по одному значениею, так что ты херней занимаешься.

_________

//wfrr

anonymous
()
Ответ на: комментарий от Donnie_Darko

>где-то на лоре видел как хвалили mongodb - человек писал что вздохнул с облегчением после того как пересел на него после 10(!) - летнего опыта с *SQL

Правда, если сравнивать с SQL, то mongo - как глоток свежего воздуха :)

С другой стороны, когда весь бэкенд сидит через ORM, то разницы уже никакой. Так что я под себя рыбу драйвера mongodb слепил, оценил, как классно оно работает на больших объёмах и... продолжаю использовать mysql ;)

Если что-то буду поднимать большое, с перспективами на масштабирование, то наверняка на mongo соответствующие объекты сделаю. А пока - старое менять смысла нет, работает, и хорошо, новое обычно делается по мелочи и на быдлохостингах без mongo :)

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← climm антиспам
Development
Есть ли «честный» аналог функции strtod? →