صفحه نخست --> موتورهای جستجو --> مقایسه موتور جستجوی Solr و ElasticSearch

مقایسه موتور جستجوی Solr و ElasticSearch

مقدمه

امروزه به علت گستره وسیع موتورهای جستجو و کارکردهای متفاوت آنها در حوزه های مختلف، انتخاب یک موتورجستجوی مناسب در راستای مرتفع کردن نیازمندی های مورد نظر مستلزم، مطالعه و مقایسه موتورجستجوهای موجود است. از این رو در این مبحث پیرامون مقایسه­ ی دو موتور جستجوی شناخته شده و مورد استفاده در بسیاری از پروژه های بزرگ با نام­ های Solr و ElasticSearch، توضیحاتی آورده شده است. این پست ابتدا به ویژگی­ های مطرح و بارز این دو محصول می­پردازد و سپس در حوزه­ های مختلف آنها را مقایسه می­کند. لازم به ذکر است که نسخه­ های مورد بررسی در این سند Solr 4 و ElasticSearch 1 می­باشند. اگر به لیست بانکهای اطلاعاتی برتر دنیا هم در سایت db-engines نگاهی بیندازید، این دو جستجوگر متن را جزء بیست بانک اطلاعاتی مطرح امروزین خواهید یافت.

مقایسه موتور جستجوی Solr و ElasticSearch
مقایسه موتور جستجوی Solr و ElasticSearch

 

 

موتور جستجوی Solr

Solr یک موتور جستجوی بسیار معروف و مورد استفاده می­باشد. این موتور جستجو متن باز بوده[۱] و محصول تیم Lucene از شرکت Apache می­ باشد. ویژگی­ های مهم آن شامل جستجوکننده قدرتمند کاملا متنی[۲]، ویژگی نشان دادن کلمات یافت شده درمتن[۳]، ویژگی جستجوی وجهی[۴]، شاخص­گذاری[۵] نزدیک به بلادرنگ[۶]، خوشه بندی پویا[۷]، یکپارچه­سازی پایگاه داده[۸]، بررسی انواع اسناد (بعنوان مثال: Word, PDF) غنی و جستجوی مبتنی بر اطلاعات جغرافیایی[۹] می­باشد. قابلیت­های غیرکارکردی Solr شامل اتکاپذیری بالا[۱۰]، مقیاس­پذیری و تحمل­پذیری خطا[۱۱]، مهیا کردن شاخص­گذاری توزیع شده[۱۲]، رونوشت داده[۱۳] و تنظیم بارگذاری[۱۴] پرس و جوها[۱۵]، تشخیص و بازیابی خودکار شکست خوردن سیستم[۱۶] و پیکربندی متمرکز[۱۷] می­باشد. Solr در خیلی از سایت­های بزرگ دنیا مورد استفاده قرار می­گیرد.

Solr به زبان جاوا نوشته شده است و می­تواند یه صورت یک Servlet در بسترهای Servlet ها چون Jetty به صورت مجزا اجرا شود. این موتور جستجو از کتابخانه جستجوی جاوا Lucene بعنوان هسته شاخص­گذاری و جستجو استفاده می­کند و رابط­های استفاده در برنامه­نویسی شبیه به REST HTTP/XML و رابط­های JSON کار با این موتور را از طریق هر زبان برنامه نویسی به طور مجازی برقرار کند. پیکربندی خارجی قدرتمند Solr اجازه پیاده سازی هر نوع برنامه­ای را بدون استفاده از جاوا و از طرفی معماری مبتنی بر افزونه این نرم­افزار قابلیت پیشرفته سفارشی سازی را در زمان نیاز فراهم می­آورد.

مقایسه محبوبیت ترند Solr و ElasticSearch در طول زمان (نمودار قدیمی است)
مقایسه محبوبیت ترند Solr و ElasticSearch در طول زمان (نمودار قدیمی است)

موتور جستجوی ElasticSearch

               ElasticSearch(ES) یک موتور جستجو و تحلیل منعطف، قدرتمند، متن باز، توزیع شده، دسترسی بالا[۱۸] و بلادرنگ می­باشد که هسته شاخص­گذار آن کتابخانه Lucene می­باشد. از ابتدا به منظور استفاده در محیط­های توزیع شده بنا شده است، جایی که اتکاپذیری و مقیاس پذیری باید وجود داشته باشد، ES توانایی حرکت آسان ماوراء جستجوی کاملا متنی ساده را به شما می­دهد. علاوه بر مجموع رابط­های برنامه نویسی تنومند[۱۹] و درخواست­های DSL(Domain Specific Language )، همچنین رابط­های زبان­های برنامه­نویسی معروف، ES وعده ­های بی­حد و حصر استفاده از فناوری جستجو را ارائه می­کند. علاوه بر قابلیت­های مذکور قابلیت­هایی دیگری نیز قابل ذکر است از قبیل

 

  • چندین شاخصی[۲۰] : یک خوشه می­تواند میزبان چند شاخصی که جدا از هم و یا به صورت یک گروه می­باشند، باشد.
  • مبتنی بر سند[۲۱] : ذخیره سازی موجودیت­های پیچیده دنیای واقعی به صورت اسناد JSON انجام می­گیرد. تمام فیلدها به صورت پیش فرض شاخص­گذاری می­شوند و تمام شاخص­ها در یک درخواست می­توانند استفاده شوند.
  • مدیریت مغایرت[۲۲] : یک کنترل کننده نسخه­ به منظور ممانعت از نابودی اطلاعات در زمان تغییرات همزمان
  • رابطRESTful : استفاده از رابط RESTful به گونه­ای که از JSON بر روی پروتکل HTTP استفاده می­کند.
  • ماندگاری در هر عملیات[۲۳] : برای ES در ابتدا امنیت داده مهم است. تغییرات اسناد در گزارش­های تراکنش­ها در چندین نود در خوشه مورد نظر ثبت می­شود تا امکان از دست رفتن داده به حداقل برسد.
  • عدم استفاده از قالب ثابت[۲۴] : ES به صورت اتوماتیک ساختار داده مورد نظر را از اسناد JSON استخراج کرده و پس از شاخص­گذاری آن را قابل جستجو قرار می­دهد. سپس بعدها با اعمال دانش خاص منظوره داده­های شما، نحوه شاخص­گذاری داده­های شما را تعیین می­کند.
مقایسه موتور جستجوی Solr و ElasticSearch
مقایسه موتور جستجوی Solr و ElasticSearch

مقایسه دو موتور جستجوی Solr و ElasticSearch

هر دو موتور جستجوی Solr و ElasticSearch مبتنی بر هسته­ی Lucene ساخته شده اند، به همین علت ویژگی­های هسته آنها یکسان می­باشد. این دو با استفاده از رابط­های برنامه­نویسی Lucene ویژگی­هایی را بر اساس آنها اضافه کرده و دسترسی به رابط­ها را به منظور استفاده در وب سرورها آسان کرده­است. در واقع تیم پیاده سازی به راحتی و با استفاده از دستورات HTTP به جای ارتباط مستقیم با Lucene و به دور از دغدغه زبان برنامه نویسی، شاخص­ها را ساخته و بر روی آنها جستجو می­کنند. برای مقایسه­ی این دو موتور جستجو در ذیل جدولی ارائه شده است که شامل تفاوت­های مهم و تاثیرگذار آنها می­باشد.

 

API

Feature Solr 6.2.1 ElasticSearch 5.0
Format XML, CSV, JSON JSON
HTTP REST API
Binary API SolrJ TransportClient, Thrift (through a plugin)
JMX support ES specific stats are exposed through the REST API
Official client libraries Java Java, Groovy, PHP, Ruby, Perl, Python, .NET, Javascript Official list of clients
Community client libraries PHP, Ruby, Perl, Scala, Python, .NET, Javascript, Go, Erlang, Clojure Clojure, Cold Fusion, Erlang, Go, Groovy, Haskell, Java, JavaScript, .NET, OCaml, Perl, PHP, Python, R, Ruby, Scala, Smalltalk, Vert.x Complete list
۳rd-party product integration (open-source) Drupal, Magento, Django, ColdFusion, WordPress, OpenCMS, Plone, Typo3, ez Publish, Symfony2, Riak (via Yokozuna) Drupal, Django, Symfony2, WordPress, CouchBase
۳rd-party product integration (commercial) DataStax Enterprise Search, Cloudera Search, Hortonworks Data Platform, MapR SearchBlox, Hortonworks Data Platform, MapR etc Complete list
Output JSON, XML, PHP, Python, Ruby, CSV, Velocity, XSLT, native Java JSON, XML/HTML (via plugin)

 

 

Infrastructure

Feature Solr 6.2.1 ElasticSearch 5.0
Master-slave replication Only in non-SolrCloud. In SolrCloud, behaves identically to ES. Not an issue because shards are replicated across nodes.
Integrated snapshot and restore Filesystem Filesystem, AWS Cloud Plugin for S3 repositories, HDFS Plugin for Hadoop environments, Azure Cloud Plugin for Azure storage repositories

 

Indexing

Feature Solr 6.2.1 ElasticSearch 5.0
Data Import DataImportHandler – JDBC, CSV, XML, Tika, URL, Flat File [DEPRECATED in 2.x] Rivers modules – ActiveMQ, Amazon SQS, CouchDB, Dropbox, DynamoDB, FileSystem, Git, GitHub, Hazelcast, JDBC, JMS, Kafka, LDAP, MongoDB, neo4j, OAI, RabbitMQ, Redis, RSS, Sofa, Solr, St9, Subversion, Twitter, Wikipedia
ID field for updates and deduplication
DocValues
Partial Doc Updates with stored fields with _source field
Custom Analyzers and Tokenizers
Per-field analyzer chain
Per-doc/query analyzer chain
Index-time synonyms Supports Solr and Wordnet synonym format
Query-time synonyms especially via hon-lucene-synonyms Technically, yes, but practically no because multi-word/phrase query-time synonyms are not supported. See ES docs and hon-lucene-synonyms blog for nuances.
Multiple indexes
Near-Realtime Search/Indexing
Complex documents
Schemaless ۴٫۴+
Multiple document types per schema One set of fields per schema, one schema per core
Online schema changes Schemaless mode or via dynamic fields. Only backward-compatible changes.
Apache Tika integration
Dynamic fields
Field copying via multi-fields
Hash-based deduplication Murmur plugin or ER plugin

 

Searching

Feature Solr 6.2.1 ElasticSearch 5.0
Lucene Query parsing
Structured Query DSL Need to programmatically create queries if going beyond Lucene query syntax.
Span queries via SOLR-2703
Spatial/geo search
Multi-point spatial search
Faceting Top N term accuracy can be controlled with shard_size
Advanced Faceting New JSON faceting API as of Solr 5.x blog post
Geo-distance Faceting
Pivot Facets
More Like This
Boosting by functions
Boosting using scripting languages
Push Queries JIRA issue Percolation. Distributed percolation supported in 1.0
Field collapsing/Results grouping
Query Re-Ranking via Rescoring or a plugin
Index-based Spellcheck Phrase Suggester
Wordlist-based Spellcheck
Autocomplete
Query elevation workaround
Intra-index joins via parent-child query via has_children and top_children queries
Inter-index joins Joined index has to be single-shard and replicated across all nodes.
Resultset Scrolling New to 4.7.0 via scan search type
Filter queries also supports filtering by native scripts
Filter execution order local params and cache property
Alternative QueryParsers DisMax, eDisMax query_string, dis_max, match, multi_match etc
Negative boosting but awkward. Involves positively boosting the inverse set of negatively-boosted documents.
Search across multiple indexes it can search across multiple compatible collections
Result highlighting
Custom Similarity
Searcher warming on index reload Warmers API
Term Vectors API

 

Customizability

Feature Solr 6.2.1 ElasticSearch 5.0
Pluggable API endpoints
Pluggable search workflow via SearchComponents
Pluggable update workflow via UpdateRequestProcessor
Pluggable Analyzers/Tokenizers
Pluggable QueryParsers
Pluggable Field Types
Pluggable Function queries
Pluggable scoring scripts
Pluggable hashing
Pluggable webapps [site plugins DEPRECATED in 5.x] blog post
Automated plugin installation Installable from GitHub, maven, sonatype or elasticsearch.org

 

Distributed

Feature Solr 6.2.1 ElasticSearch 5.0
Self-contained cluster Depends on separate ZooKeeper server Only Elasticsearch nodes
Automatic node discovery ZooKeeper internal Zen Discovery or ZooKeeper
Partition tolerance The partition without a ZooKeeper quorum will stop accepting indexing requests or cluster state changes, while the partition with a quorum continues to function. Partitioned clusters can diverge unless discovery.zen.minimum_master_nodes set to at least N/2+1, where N is the size of the cluster. If configured correctly, the partition without a quorum will stop operating, while the other continues to work. See this
Automatic failover If all nodes storing a shard and its replicas fail, client requests will fail, unless requests are made with the shards.tolerant=true parameter, in which case partial results are retuned from the available shards.
Automatic leader election
Shard replication
Sharding
Automatic shard rebalancing it can be machine, rack, availability zone, and/or data center aware. Arbitrary tags can be assigned to nodes and it can be configured to not assign the same shard and its replicates on a node with the same tags.
Change # of shards Shards can be added (when using implicit routing) or split (when using compositeId). Cannot be lowered. Replicas can be increased anytime. each index has 5 shards by default. Number of primary shards cannot be changed once the index is created. Replicas can be increased anytime.
Shard splitting
Relocate shards and replicas can be done by creating a shard replicate on the desired node and then removing the shard from the source node can move shards and replicas to any node in the cluster on demand
Control shard routing shards or _route_ parameter routing parameter
Pluggable shard/replica assignment Rule-based replica assignment Probabilistic shard balancing with Tempest plugin
Consistency Indexing requests are synchronous with replication. A indexing request won’t return until all replicas respond. No check for downed replicas. They will catch up when they recover. When new replicas are added, they won’t start accepting and responding to requests until they are finished replicating the index. Replication between nodes is synchronous by default, thus ES is consistent by default, but it can be set to asynchronous on a per document indexing basis. Index writes can be configured to fail is there are not sufficient active shard replicas. The default is quorum, but all or one are also available.

 

Misc

Feature Solr 6.2.1 ElasticSearch 5.0
Web Admin interface bundled with Solr Marvel or Kibana apps
Visualisation Banana (Port of Kibana) Kibana
Hosting providers WebSolr, Searchify, Hosted-Solr, IndexDepot, OpenSolr, gotosolr Found, Scalefastr, ObjectRocket, bonsai.io, Indexisto, qbox.io, IndexDepot, Compose.io, Sematext Logsene

 

 

قابلیت­های مورد بررسی

Solr 4

ElasticSearch 1

نتیجه بررسی

Foundation

·    در سال ۲۰۰۸ میلادی منتشر شد.

·    با هدف پوشش ویژگی­های جدید جستجو بنا نهاده شد.

·    در سال ۲۰۱۲ با توجه به ویژگی جدید توزیع شدگی SolrCloud را منتشر کرد.

·     در سال ۲۰۱۰ میلادی منتشر شد.

·     با هدف پوشش ویژگی توزیع شدگی جستجو بنا نهاده شد.

به دلیل هدف معماری ES و نحوه پیاده سازی آن راه اندازی یک خوشه­ی ES راحتتر و ساده تر از راه اندازی یک خوشه SolrCloud می­باشد.

Coordination

·    از ZooKeeper استفاده می­کند.

·    به یک سرور مجزا برای ZooKeeper احتیاج دارد.

·    در هر Shard به یک رهبر احتیاج دارد.

·     از ZenDiscovery استفاده می­کند.

·     فقط از نودهای ES استفاده می­شود.

·     در مجموع به یک رهبر احتیاج دارد.

برای راه اندازی SolrCloud علاوه بر راه اندازی Solr احتیاج به راه­اندازی ZooKeeper نیز وجود دارد. در صورتی که برای راه اندازی ES به اجزاء دیگری احتیاج نیست. از طرفی هنگام کار با Solr درگیری تقسیمات فکری در خصوص مسائل خوشه­ها و نودهای آنها کمتر می­باشد.

Shard Splitting

·    Shard ها می­توانند در زمان اجرا اضافه و یا تقسیم شوند، اما نمی­توان تعداد آنها را کم کرد.

·    رونوشت­های داده را در هر زمان می­توان اضافه نمود.

·     نمی­توان تعداد Shard­ها را در زمان اجرا تغییر داد، اضافه و یا تقسیم کرد.

·     رونوشت­های داده را در هر زمان می­توان اضافه نمود.

در این قابلیت که Solr حاوی آن می­باشد. در زمان­هایی که امکان تغییر نودها و Shardها وجود دارد استفاده از Solr بسیار توصیه می­شود. زیرا در صورت استفاده از ES می­بایست تمام اطلاعات دوباره شاخص­گذاری شوند.

Automatic Shard Rebalancing

·    چنین قابلیتی وجود ندارد.

·     با تنظیم مجزای تعداد نودها و تعداد Shard­ها و رو نوشت­های آنها از ابتدای فرآیند، در صورت تغییر نودها، جابجایی Shard­ها و رونوشت آنها به نودهای جدید به صورت خودکار انجام می­پذیرد.

در شرایطی که امکان افزایش تعداد Shardها در آینده به علت افزایش سخت­افزار  وجود دارد، می­توان با افزایش تعداد Shardها در ابتدای فرآیند از پردازش­های احتمالی جهت تغییر Shardها جلوگیری کرده و در صورت افزایش نودها توازن بارگذاری و جابجایی Shardها و رونوشت­ها به صورت خودکار انجام می­پذیرد.

Scheme Creation And Scheme-Less Fields

·    ساخت قالب می­بایست قبل از شاخص­گذاری صورت گیرد و در زمان اجرا امکان پذیر نمی­باشد.

·    می­توان در زمان اجرا فیلدهای با نوع پویا را علاوه بر قالب از پیش تعیین شده، شاخص­گذاری کرد.

·    نمی­توان در هر قالب انواع متفاوتی در یک فیلد در نظر گرفت.

·     ساخت قالب بر اساس داده ورودی در زمان شاخص­گذاری صورت می­گیرد و نوع فیلدها به صورت خودکار تشخیص داده می­شود.

·     می­توان در زمان اجرا فیلدهای با نوع پویا را علاوه بر قالب، شاخص­گذاری کرد.

·     می­توان در یک قالب انواع مختلفی از یک فیلد را تعریف کرد.

در صورتی که تغییرات داده­ی مورد نیاز جهت شاخص­گذاری بسیار کم باشد استفاده از قالب توصیه می­شود و در غیر اینصورت هر دو موتور با توجه به تفاوت زمان ساخت قالب و تشخیص نوع فیلدها قابلیت تغییر در نحوه شاخص­گذاری را ارائه می­دهد. اما در صورتی که نوع داده ورودی و فیلدهای آن تغییرات داشته باشد به علت تشخیص خودکار و شاخص­گذاری به هر نحو استفاده از ES توصیه می­شود.

Nested Typing

·    چنین قابلیتی وجود ندارد.

·     اسناد می­توانند شامل اسناد دیگری باشند. بعنوان مثال سند اطلاعات یک شخص حاوی سند آدرس خانه آن شخص نیز می­تواند باشد.

·     در صورت استفاده نامناسب در صورت بروزرسانی و تغییر اسناد، تاثیر منفی در عملکرد شاخص­گذاری دارد.

·     تمام اطلاعات کل سند در یک Shard باید بتواند ذخیره شود و ذخیره می­شود.

·     می­توان اسناد والدین را براساس اسناد فرزندها مرتب کرد.

·     می­توان با استفاده از این اسناد و رابطه والدین و فرزندی عملیات الحاق را انجام داد.

در صورت نیاز به عملیات الحاق و ارتباط والدین و فرندان بین اسناد می­توان از این نوع ساختار اسناد در موتور ES استفاده کرد.

Query Syntax

·    بر مبنای کلید و مقدار و بصورت تو در تو (با استفاده از پرانتز) کار می­کند.

·     با استفاده از JSON درخواست­ها ساخته و ارائه می­شود.

این بخش بستگی به میزان راحتی و آسانی استفاده کاربران از هر کدام از این دو نوع املاء درخواست دارد.

Filters

·    می­توان از تجزیه کننده­های مختلف استفاده کرد.

·    می­توان از پارامترهای محلی استفاده کرد.

·    نتایج جستجوهای وجهی را تحت تاثیر قرار داده و در جهت هدف کاهش می­دهد.

·     با استفاده از درخواست­های DSL تعریف می­شود.

·     می­توان از آن در محاسبات امتیازدهی استفاده کرد.

·     نتایج جستجوی وجهی را تحت تاثیر قرار نداده و میزان آن را کاهش نمی­دهد.

بر مبنای استفاده کاربر وابسته است. هر کدام، قابلیت­های خود را دارا می­باشند.

Hash-Based Deduplication

·    این قابلیت به منظور استفاده از یک فیلد خاص به جای شناسه سند پیش فرض جهت حذف تکرار و یکتایی واقعی اسناد می­باشد.

·     چنین قابلیتی وجود ندارد.

این قابلیت به منظور استفاده در شرایطی چون زمانی که محتویات اسناد مختلف یکسان باشند و هدف یکتایی معنایی باشد به کار می­آید.

Plugins

·    می­توان در جریان کار جستجو و بروزرسانی استفاده کرد.

·    می­توان در انواع روش­های درهم سازی از آن استفاده کرد.

·     می­توان در جریان امتیازدهی از آن استفاده کرد.

·     می­توان در ارتباط با برنامه­های تحت وب از آن استفاده کرد.

·     فرآیند خودکار نصب افزونه­ها

بر مبنای استفاده کاربر وابسته است. هر کدام، قابلیت­های خود را دارا می­باشند.

Distributed Group By

·    این قابلیت در واقع دسته­بندی زمینه­هایی چون مرتب کردن، فیلتر کردن، جستجوی وجهی و … به صورت توزیع شده انجام می­دهد.

·     چنین قابلیتی وجود ندارد.

در صورت نیاز به دسته بندی نتایج مختلف به صورت توزیع شده این قابلیت بسیار کاربردی می­باشد.

Percolation Queries

·    چنین قابلیتی وجود ندارد.

·     در این قابلیت موتور با ذخیره­ درخواست­های متنوع، در صورتی که اسناد ورودی در حوزه­ی پاسخ آن درخواست­ها باشد، اطلاع می­دهد.

·     در صورت زیاد بودن درخواست­های ذخیره شده، عملکرد موتور در زمان شاخص­گذاری کاهش می­یابد.

از این قابلیت در شرایطی که احتیاج به هشدار در صورت ورود سند خاص مد نظر باشد می­توان استفاده کرد.

Pivot Faceting

·    انجام جستجوهای چند وجهی بر مبنای اولویت­بندی وجوه می­باشد و در واقع یک درخت تصمیم را شکل می­دهد.

·     چنین قابلیتی وجود ندارد.

از این قابلیت در جستجوهایی که چندین پارامتر از اسناد را همزمان بررسی می­کنند و اولویت دسته­بندی این پارامترها مهم می­باشد، استفاده می­شود.

Histograms

·    چنین قابلیتی وجود ندارد.

·     این قابلیت نمودارهایی در بازه­های زمانی و غیر زمانی مبتنی بر فیلدها در پاسخ به درخواست وجوه مورد نظر ارائه می­کند.

از این قابلیت برای ساختن نمودارهای متنوع و آماری از داده­های موجود در بازه­های عددی و زمانی متفاوت استفاده می­شود.

Hadoop Integration

·    در خصوص ادغام و استفاده از Hadoop، تا این لحظه افزونه و یا نرم­افزاری که با استفاده از Hadoop به پردازش محلی اطلاعات ذخیره شده در شاخص Solr بپردازد وجود ندارد.

·     در سایت مرجع ES، ادغام با Hadoop به عنوان یکی از ویژگی­ها و افزونه­های این موتور جستجو در نظر گرفته شده است، به گونه­ای که می­توان اطلاعات ذخیره شده را به طور محلی بارگذاری و پردازش کرده و نتیجه را با استفاده از MapReduce گردآوری کرده و ارائه می­کند.

تا این لحظه فقط موتور ES این قابلیت را دارا می­باشد.

Distributed Replication

·    Solr پس از تایید در ساختن شاخص اسناد ورودی، پس از اینکه فایل یک تکه و به هم پیوسته شاخص­ها توسط Lucene تولید شد، آن را در نودها کپی می­کند.

·     ES به جای آنکه فایل تولیدی را یکجا کپی کند، هر سند را به تمام نودها ارسال می­کند و از آن کپی می­گیرد.

در Solr در صورتی که نرخ داده ورودی بسیار کم باشد و همه داده به یکباره شاخص­گذاری شود خوب کار می­کند و در صورتی که نرخ جریان داده متغیر باشد ES خیلی بهتر جواب می­دهد. از طرفی هم در صورتی که یکی از نودها از خوشه حذف شود در موتور ES به علت کامل بودن تمام رونوشت­ها به راحتی نود مورد نظر جایگزین می­شود.

Users

·    Solr به علت قدمت بیشتر نسبت به ES از کاربرهای بیشتری برخوردار است و در نتیجه دارای مباحث و آموزش­های غنی­تری نیز می­باشد.

·     ES به علت نو ظهور بودن در عرصه موتورهای جستجو دارای کاربران کمتری می­باشد ولی رشد فوق العاده­ای دارد.

در حال حاضر Solr دارای کاربران بیشتری می­باشد و بلاگ­ها و مباحث بیشتری را پوشش می­دهد.

 

 

نتیجه گیری

با توجه به این که هسته شاخص­گذار هر دوی این موتورهای جستجو Lucene می­باشد، در بسیاری از ویژگی­ ها کاملا یکسان عمل می­کنند. در بین ویژگی هایی که ذکر شد نقش فناوری جستجو و فناوری توزیع شدگی پر رنگ­تر از باقی نکات می­باشد. در واقع باید این مطلب را اشاره کرد که هردوی این موتورها در راستای اهداف خود گام برداشته و موفق بوده­اند. Solr با قابلیت­هایی مرتبط با کیفیت جستجو و روش­های آن و نیز راحتی کاربر در استفاده از روابط کاربری تعبیه شده بسیار موفق بوده است. ES نیز با قابلیت­های مرتبط با آسانی راه­اندازی توزیع شدگی و ادغام با نرم­افزارهای مختلف علمی و پارامترهای مختلف خاص جستجو، با توجه به قدمت کمتر، بسیار موفق بوده است. از طرفی به علت پیشرفت روز افزون این محصولات در تمام عرصه­ ها تفاوت­های آنها در بخش­های مختلف پوشش خواهد داده شد. با وجود تمام این نکات انتخاب از بین این دو موتور جستجو بسیار وابسته به نیازمندی­های پروژه می­باشد. در صورتی که توزیع شدگی و داده بسیار بزرگ و تجاری مد نظر می­باشد ES انتخاب بهتری می­باشد و در صورتی که پوشش انواع ارتباطات کاربری و جستجوهای خاص و یادگیری مد نظر باشد Solr گزینه مناسب­تری می­باشد.

منابع :

http://lucene.apache.org/solr

http://www.elasticsearch.org

http://solr-vs-elasticsearch.com

http://thinkbiganalytics.com/solr-vs-elastic-search

http://alexdong.com/one-fundamental-difference-between-elasticsearch-and-solr

http://db-engines.com/en/system/Elasticsearch%3BSolr

https://db-engines.com/en/blog_post/70

.https://sematext.com/blog/solr-vs-elasticsearch-differences/

آدرس کانال تلگرام ما:

t.me/bigdata_channel
برای ورود به کانال بر روی اینجا کلیک کنید.

[۱] Open Source

[۲] Full-Text Search

[۳] Hit Highlighting

[۴] Faceted Search

[۵] Index

[۶] Real-Time

[۷] Dynamic Clustering

[۸] Database Integration

[۹] Geospatial Search

[۱۰] High Reliability

[۱۱] Scalable and Fault-Tolerant

[۱۲] Distributed Indexing

[۱۳] Replication

[۱۴] Load-Balancing

[۱۵] Queries

[۱۶] Automated Failover and Recovery

[۱۷] Centralized Configuration

[۱۸] High Availablity

[۱۹] Robust

[۲۰] Multi-Tenancy

[۲۱] Document Oriented

[۲۲] Conflict Management

[۲۳] Per-Operation Persistence

[۲۴] Scheme Free

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *