piątek, 5 września 2014

Create your own content repository (Content Management Systems based on Spring Boot + GridFS)

Ok. Posty powinny być krótkie więc... dziś krótko i do rzeczy.
Jakiś czas temu publikowałem materiały na temat baz Nosql. Potem przeszedłem do bazy Neo4j. Ten post powstał dopiero w pierwszej części i niedługo dokończę publikacje :)


Teraz padło na MongoDB.


Wyzwanie jest następujące : przetrzymywać treści nie ważne czy to rysunki, dokumenty pdf czy inne tworzy binarne. Wielkość tych pakunków ma być rozsądna do kliku MB.





1. Research -> Google 
  - blob +standardowe bazy relacyjne - słabe podejście(wydajność,skalowalność)
  - system plikowy + rsync - już dużo lepiej wymaga zaimplementowania jakiegoś serwera plików czy treści
  - jackrabbit - trudniej integruje się ze Springiem, najbardziej rozbudowane i zaawansowane ze wszystkich tutaj wymienionych
  - GridFS  - Łatwa integracja ze Spring oraz Spring Boot. Idealne na skalowane repo dokumentów. Posiada też proste API. Wydaje się być optymalne do moich potrzeb.Pozostałe potrzebne dane oraz dokumenty około elementów dziedziny możemy trzymać w bazie MongoDB.

GridFS to dwie kolekcje :
  - chunks - zawiera binarne kawałki danych. (zwykle rozćwiartowane na kawałki po 256KB)
  - files - zawiera meta dane do powyższych binariów (zawiera informacje o nazwie pliku, wielkości, sumie kontrolnej, ekstra informacje dostarczone przez użytkownika,)
Dostęp do nich otrzymyjemy odpowiednio przez :
  - fs.files
  - fs.chunks

Dokładny opis pól z namespace fs znajdziesz tutaj.

TIP : fs - to default namespace, zawsze możemy stworzyć nowe np żeby przechowywać inny typ plików.

TIP : GridFS najlepiej sprawdza się w przypadku większych plików, przechowywanie małych może powodować problemy wydajnościowe.

Dane zapisywane są w postaci BSON o limicie 16MB. Jeśli chcesz włożyć większy kawałek danych musisz go podzielić na kilka dokumentów.
Pliki są replikowane pomiędzy instancjami mongoDB. Usunięcie lub włożenie danych binarnych z jednej powoduje propagacje działania na inne bazy.  

 2. Założenia
Chce aby aplikacja była przenośna i mogła działać w chmurze. Sprawdzam MongoDB na Heroku, więc jest ok.
Pragnę stworzyć aplikacje w duchu microservices, wybór jak Spring Boot jest jak najbardziej odpowiedni.

W części następnej chce wystawić REST + WS-* API. Muszę zaimplementować też security. Zależy mi na tym aby aplikacja działała podobnie jak w chmurach. Pobieranie i udostępnianie zasobów -> Token -> w prostej linii kieruje mnie to w stronę Auth2.

Projekt ma być szybki i pokazać, że szybko można też coś sensownego zrobić.
Publikuje na razie wersję bez REST API.


TIP : w stosunku do Spring Security opłaci się stosować podejście hybrydowe. Co to oznacza ? Tyle , że całość implementuje w Java Config a konfigurację security ze względu na czytelność lepiej wydaje się pozostawić w plikach XML.
Wygląda to tak jak poniżej.


Konfiguracja MongoDB + Spring Boot

Konfiguracje mongoDB repo - tak na wszelki wypadek np na metaDane
Konfiguracja ustawień - yaml

Wstępne API
Implementacje API
Testujemy API


Z perspektywy mongoDB:
Szukanie pliku:
mongo klient szukanie pliku :
Możemy użyć poleceń konsoli przez program : mongofiles
 - mongofiles put 2.png - włóż do GridFS
 - mongofiles list - listuj
 - mongofiles delete 2.png - usuwanie pliku
 - mongofiles get 2.png - pobranie z bazy na dysk
 - mongofiles search 2.png - szukaj plików

szukanie :
usuwanie :












To co się dzieje w bazie podczas użycia programowego dostępu do danych.

































Kod do posta jest tutaj.

Krótkie podsumowanie : mamy bazę do tworzenia rozmaitych rozwiązań. Nie jest to pełen CMS a jego zalążek czyli tylko składowanie binariów ich meta-danych. Do wielu zastosowań to wystarczy.





Brak komentarzy:

Prześlij komentarz