2012-05-22 7 views
5

Ich möchte meine Datenbank shard, aber ich bin nicht professionell in diesem Thema. Also hier sind meine Überlegungen. Obwohl sharding key ein ausgezeichneter Index ist, um Anfragen an die richtigen Knoten zu richten, was ist mit den restlichen Indizes, die in meinen Tabellen definiert werden? Ich möchte, dass Anfragen, die auf diese Indizes verweisen, auch an die richtigen Knoten geliefert werden, sodass nur ein Knoten die Anfrage verarbeitet. Soweit ich das für diesen Zweck verstanden habe, müssen einige zentralisierte Indexknoten existieren. Meine Frage ist also, ob diese Funktionalität bereits in RDBMS wie MYSQL vorhanden ist oder ob ich andere spezielle Produkte verwenden soll.Sharding und Indizes

Antwort

0

Disclaimer: Ich für ScaleBase arbeiten, ich leben und atmen jeden Tag Sharding ...

Ich würde hier darauf hinweisen, dass, wenn Sie Scherbe nach Spalte A zum Beispiel ein, wo man mit columnA = xx a gehen einzelne Shrad. WHERE columnB = xx muss alle Shards durchlaufen, da in allen Spalten columnB = xx enthalten sein kann. Es sei denn columnA und columnB sind verwandt. Und dann müssen Sie die Beziehung wirklich in einer Zuordnungstabelle speichern. Ich kann sagen, dass auf allen DBs laufen kann superschnell sein, müssen Sie parallel laufen und Ergebnisse zusammenführen. Bei ScaleBase unterstützen Verschmelzung wir ORDER BY, GROUP BY usw. Es ist nicht einfach ...

Hey weitere Informationen in meinem Blog sehen: http://database-scalability.blogspot.com

+0

Ja, das verstehe ich nicht. Wenn Sie separate Knoten haben, die db-Indizes zugeordnet sind (physische Position + Maschinen-ID), können Sie jede Abfrage, die auf die Spalte B verweist, nur auf die Maschinen anwenden, auf denen sich die Daten tatsächlich befinden! Das ist schneller! –

0

Andrey, was Sie beschreiben genau, wie die Clustrix Datenbank funktioniert, wo Daten und Indizes werden automatisch verteilt, dann werden Abfragen über Knoten verteilt. Clustrix "brings the query to the data" und hat eine Shared-Nothing-Architektur (daher wird kein zentralisierter Index benötigt). MySQL hat keine integrierte Funktionalität für verteiltes Rechnen, und obwohl verschiedene Bolt-On-Optionen zur Verfügung stehen, stoßen sie bei der Begrenzung der zentralisierten Ressourcen auf Skalierungsgrenzen.