Разработвам приложение, което ще използва три таблици. 1 - 1 милион реда продукти. 2 - 500 милиона реда потребители. 3 - 10 милиарда реда продукти, които потребителите харесват. таблиците ще растат с времето, но ще останат около тези числа. искам да избера правилния метод за този вид DB. Наистина не знам много за шардинга, групирането или разделянето, но ако някои от вас може да ми каже най-доброто решение за този проблем, ще се съсредоточа върху него и това ще бъде от голяма полза. искам само методи, които поддържат mysql и ако имам нужда от множество сървъри за този вид DB? Благодаря.
нуждаем се от помощ при избора на правилния метод за mysql DB шардинг, групиране или разделяне
Отговори (2)
Можете да разделите този набор от данни доста лесно, но може да не се наложи в зависимост от типа анализ, който се опитвате да направите. Ако това е просто история на това, което всеки потребител харесва, тогава вероятно можете да използвате разделяне на база данни за разделяне на данните по диапазон на дата и след това подразделяне на user_id.
Ако често актуализирате датата (потребителите могат да „не харесват“ неща), тогава вероятно трябва да погледнете шардинга. Тук има примерна реализация на шардинг: Shard-Key-Mapper. Можете да изпълнявате разпределени паралелни заявки върху набора от данни (като map/reduce за SQL) тук: Shard-Query.
Ако шардите, трябва да предложа шардинг по user_id и запазване на таблицата с продукти като „споделена“ таблица, която се дублира на всеки шард. Трябва да използвате метод за шардинг, базиран на директория, който ви позволява да премествате потребител между шардове. Цялата информация за един потребител и информацията за това, което харесва, ще се съхраняват заедно на един шард.
person
Justin Swanhart
schedule
08.05.2011
Мисля, че ако наистина не искате noSQL решение като Hadoop, не можете да избегнете получаването на множество сървъри за бази данни (тук: MySQL). А репликацията на MySQL според мен не осигурява достатъчно мащабируемост за този вид данни, защото главният ще се превърне в тясното място. Аз също не съм професионалист по скалируемост, но в момента също мисля за хубаво решение за подобен проблем от моя страна. Мисля, че ще използвам решение за шардинг, при което разделям данните си на множество възли. Просто си мисля за интелигентен начин за създаване на картографиране от данни към фрагмент. Но това зависи от вашето приложение как искате да го направите. Мисля, че вашите данни за „харесване на продукта“ са добър кандидат за разделяне, защото са толкова огромни.
Между другото: Интересна статия срещу шардинга: http://37signals.com/svn/posts/1509-mr-moore-gets-to-punt-on-sharding
person
H6.
schedule
02.05.2011
