Narzędzie wyszukiwania w Meteor JS

Question

Jestem dość początkujący, jeśli chodzi o DB i wyszukiwania, więc proszę o mnie. Próbuję wprowadzić funkcję wyszukiwania w aplikacji Meteor. Sprawdziłem przez atmosferę i trafiłem na te 4 opcje.

1. Mattodem łatwe wyszukiwanie
2. Szukaj Źródło
3. Elastyczny pakiet szukaj w atmosferze (usłyszałem ten jest datowany)
4. Elastic duży pakiet danych na Atmosphere

Moje potrzeby są dla prostego wyszukiwania , w stanie obsłużyć większe zestawy danych, które mogą zawierać zagnieżdżanie danych. Na przykład zadanie, może mieć komentarze lub linki itp. (Pełny tekst i więcej niż zapytanie regex będzie dobre)

Czytam, że do łatwego wyszukiwania, nawet w przypadku jakiejś formy elastycznej lub aplikacji Mongodb, wydaje się być tylko aplikacją w przypadku pojedynczej kolekcji Mongo? Na przykład co, jeśli chcę przeszukać Dinosaurs = new Meteor.Collection('dinosaurs'); i Mammals = new Meteor.Collection('mammals');?

Doceń porady dotyczące plusów i minusów na 4 powyższych opcjach? 1 wydaje się względnie łatwe do wdrożenia, ale nie jestem pewien, co to znaczy, używając elastycznego silnika here. Jeśli miałbym zastosować elastyczne, jak mam to zrobić w Meteor? A czy różni się on od implementacji API HTTP Elasticsearch?

Podobnie, jak w przypadku źródła wyszukiwania, obsługuje także elastyczną wersję here. Szczerze mówiąc nie mam pojęcia o różnicach.

projekt

Answer 1

github ten demonstruje, jak używać Meteor z ElasticSearch (nie Mongo) dla aplikacji wyszukujących

https://github.com/hharnisc/meteor-elasticsearch-demo/tree/master/elasticsearch-demo/packages/elastic-collection

to w zasadzie linki pole do zmiennej sesji, która wyzwala wyszukiwanie na elastyczne. wyniki są przechowywane w kolekcji mongo, która jest przekazywana klientowi za pośrednictwem mechaniki Meteor. Są one znacznie mniejsze niż zestaw danych i dlatego można je szybko zaktualizować.

Jeśli chodzi o wyszukiwanie w kolekcjach, jest to typowy problem z definicją schematu bazy danych. Jeśli chcesz zrobić sprzężenia, mongodb nie jest najlepszym rozwiązaniem. i relacyjny DB jak każdy SQL DB byłby lepiej dopasowany, jednak powinieneś zajrzeć do 'denormalizacji' swoich danych, aby sprawdzić, czy możesz stworzyć strukturę, która będzie dobrze działać w twoim przypadku użycia.

Ten artykuł wyjaśnia, co to znaczy całkiem dobrze:

http://blog.mongodb.org/post/87892923503/6-rules-of-thumb-for-mongodb-schema-design-part-2

powodzenia.