MapReduce za pomocą SQL Server jako źródła danych

Question

Obecnie badam możliwość użycia MapReduce do utrzymania przyrostowych kompilacji widoku w SQL Server.

Zasadniczo użyj funkcji MapReduce, aby utworzyć widoki zmaterializowane.

Trochę utknąłem w bankomacie. myśląc o tym, jak podzielić moje wyjścia map. Teraz tak naprawdę nie mam sytuacji BigData, z grubsza 50 GB to maksimum, ale mam dużo złożoności i rodzaju dorozumianych problemów z wydajnością. Chcę sprawdzić, czy moje podejście do MapReduce/NoSQL może zostać usunięte.

Rzecz o MapReduce, z którą obecnie mam problemy, to partycjonowanie. Ponieważ używam SQL Server jako źródła danych, lokalizacja danych nie jest tak naprawdę moim problemem i dlatego nie muszę wysyłać danych w każdym miejscu, raczej każdy pracownik powinien mieć możliwość pobrania partycji danych bazować na definicji map.

Zamierzam w pełni zmapować dane za pomocą LINQ i może coś w rodzaju Entity Framework, tylko po to, aby zapewnić znajomy interfejs, jest to nieco poza punktem, ale jest to aktualna trasa, którą badam.

Teraz, jak podzielić dane? Mam klucz podstawowy, mam definicje map i reduce w kategoriach drzewek wyrażeń (AST, jeśli nie znasz LINQ).

• Po pierwsze, w jaki sposób opracować sposób dla mnie, aby podzielić całą wejście i partycjonowanie początkowego problemu (myślę powinienem być w stanie wykorzystać agregaty okno w SQL Server, takie jak ROW_NUMBER i TILE).

• Po drugie, i co ważniejsze, w jaki sposób mogę się upewnić, że robię to stopniowo? Oznacza to, że jeśli dodam lub zmieniłem pierwotny problem, w jaki sposób mogę skutecznie zminimalizować liczbę ponownych obliczeń, które trzeba wykonać?

Szukałem na CouchDB inspiracji i wydają się mieć sposób, aby to zrobić, ale w jaki sposób mogę wykorzystać część tej dobroci przy użyciu SQL Server?

Answer 1

Mam do czynienia z czymś podobnym. Myślę, że powinieneś zapomnieć o funkcjach okienkowania, ponieważ sprawia to, że twój proces jest serializowany. Innymi słowy wszyscy pracownicy będą oczekiwać na zapytanie.

To, co przetestowaliśmy i działa "to", to podzielić dane na więcej tabel (co miesiąc ma swoje tabele x) i uruchomić oddzielne wątki analityczne na takich partycjach. Oznakowanie przetworzonych/nieprzetworzonych/ewentualnie złych/itp. Danych po zmniejszeniu.

Testy z jednym podzielono tabeli przyniósł jako kwestii eskalacji zamek ..

Będziesz na pewno dodać trochę więcej złożoność obecnego rozwiązania.