I love Phalcon, but it does not come with Couchbase whereas Couchbase provides ODM and SDKs (Dlls for XAMPP / WAMPP) for PHP. Can you please compile Phalcon with Couchbase SDKs / ODM ?
I am looking for Couchbase because so far Couchbase is the best of all NoSQL servers I have worked with. It supports distributive memcache-compatible in-memory Key-Value store as well as Document Store. Also, it allows N1QL (SQL-like Data Query language), Eventing Services using JavaScript and much more. It supports Full-Text Search with Fuzzy-Search as optional parameter. It is lightning fast and features-rich as compared to other NoSQL. It also offers Enterprise version with Enterprise-level support. Note that Doctrine-2 supports Couchbase, but I want it with Phalcon, not with any thick-layered ORM.
Related
I'm currently working on an architecture with an offline mobile client and a database server.
I was thinking about using the sync-gateway component from couchbase, hence, couchbase as a server db and pouchdb as a client db.
The business logic is quite complex, though and as far as I understand, synchronization filtering, data validation and authorization is made through the gateway configuration.
Is this a good idea or couchbase synchronization capabilities are preferred for simpler logics and I should stick to a more Spring Rest API and fill the local indexDB manually.
Couchbase Sync Gateway is used in very large enterprise grade deployments of varying complexity and scale so that shouldn't be an issue. The decision you would need to make is whether you need sync or you are looking for a simple request-response approach (that's better suited for connected environments). FWIW, Sync Gateway also supports a REST interface - so you can use indexedDB requesting data via the REST interface as well.
You mention offline mobile client so why are you not using couchbase lite as the embedded database? Is this a PWA? The synchronization protocol between Couchbase lite and Sync Gateway is more performant and advanced compared to the couchDB based approach used between the likes of PouchDB and Sync Gateway.
We have a microservice-based application which is developed in Spring Boot. Let us assume there are 3 microservices A, B, and C. The front-end is written using Angular and the backend comprises MySQL database and Hibernate for ORM. We are required to implement a full-text search functionality that will have a search box on the UI where the user can enter the text of his choice. The search must be able to return data from databases from all the 3 microservices. I am facing difficulty in finalizing the search technology for the same. Some of the technologies I have in my purview are
Hibernate Search
Apache Solr
ElasticSearch
Which is the best technology for this problem? If possible, are there any examples of the same?
Hibernate search looks to be depending on internal search solution for it to be providing full text search which could be either plain Apache Lucene or Elasticsearch. I'm not sure but its Elasticsearch integration if its already matured as version 6.0 is still in development stage.
The older/stable version of Hibernate search i.e. 5.11 supports Elasticsearch 2.0 to 5.6.
But looking at your queries, it depends on what you uses case you have. Perhaps below points would help you.
What is the size of the data you have and what is the expected growth rate of your documents/data.
What would be your write vs read rates for this application?
What type of search use-cases you have? What features of search are you looking for? for e.g. Autocomplete, autosuggestion, highlighting, faceted-search
Are you looking for a distributed search or do you have a limitation in using hardware?
Is there a requirement to support search in multiple-languages?
Is that only text search would suffice or would you also be doing analysis on the search logs or click-view data in the future?
What options do you have when it comes to ingesting documents into your search engine. If its Elasticsearch you can easily make use of Beats or Logstash. Or you can simply dump raw data into ES, and then make use of a combination of Ingest API to do pre-processing/enrichment/filtering and then again push the processed data in different index in Elasticsearch.
Both Solr and Elasticsearch are great technologies but if you have to use one of them, I would strongly suggest in using Elasticsearch because it would help you in all of the above queries, much more powerful distributed model, it has it own amazing DSL which is very mature and easy to use, has excellent administrative tools/API for data managment, It is extremely fast and easy to set up. Not to mention their aggregation queries which helps you get analytical information about the documents you'd have ingested.
You would also have the luxury of setting up your own dashboard via Kibana which would help you quickly create some great visualizers.
Plus point is it is completely RESTful by nature, so that means it makes your life easier when it comes to deployment of your applications. I'd suggest you to start from here and spend sometime in understanding the technology.
Hope this helps!
For fulltext search Elasticsearch and Apache Solr are the best choices from the given selection.
However, I strongly disagree that Elasticsearch is better than Solr or other way around without knowing more info about your business case. Both technologies will perform equally for the given problem since they are both build upon Apache Lucene search engine.
They both offer great REST CLients.
Here you can check out example implementation of both - Apache Solr and Elasticsearch in the same project in Java. You can also check what are the differences and which one do you prefer.
Also, there are six write-ups on how to use Apache Solr and Elasticsearch written here. Last chapter is about research which shows that both engines are almost equal and have differences only in very specific business cases. Both have many supporting tools as well.
I want to use aws for hosting a django application and use aws rds for database purpose. The application is kind of blog like system.
I am not able to decide which RDS I should choose over MySql or Postgres? Both price wise and performance wise according to aws pricing policy.
This can be very broad and may be opinionated , I would try to keep it short as i read it somewhere:
MySQL would be very good for any CMS Site as it works very well with it and MyISAM tables are quite nice here.
From What I read where PostgreSQL does better than MySQL:
Multi-application databases
Advanced data modelling
What Advance Data Modelling means is that PostgreSQL is far more mature at doing complex data modelling than MySQL is. It has a very mature extensible type system, a wide range of procedural languages, and a great deal of flexibility in how these languages can be plugged into existing queries.
If that wasn't enough, the fact is that you can essentially build your data model in PostgreSQL based not only on what information you are storing but what information is commonly derived from what you are storing. This makes things like not-first-normal-form actually sane to use where they are needed. Add collections and multiple inheritance in table structure and you have a very sophisticated data modelling platform, this blog would help you understand it better.
Besides the content management system market, MySQL's other major market is in applications where data is not expected to be exposed to more than one writing application at a time. This leads to a significant difference in handling data validation, etc.
In PostgreSQL validation is always equally strict. If the app expects special error treatment it had better call functions or casts to handle this explicitly.
MySQL however places the application in charge of defining the data validation rules.So while PostgreSQL allows the relational and object-relational interface to serve as a public API, it is essentially intended largely to be a private API for applications in MySQL. This is a huge difference and not readily understood by many people trying to make the choice. This leads to major differences in application design.
MySQL is a data storage and reporting solution for your application.
PostgreSQL is a data centralization, modelling, and reporting solution
for your organization. The two are remarkably different.
Now coming to Second Question based on pricing as you can see from MySQL Pricing Page and PostgreSQL Pricing Page MySQL is bit cheaper than PostgrSQL , reading on the answer you can make informed decision what would be best for you.
Hope this Helps!
I'm gonna offer you a 3rd option: Aurora - try it. It's cheaper than those 2 and is MySQL compatible.
This article may be of help to you when deciding.
For simple blog-like thingie I'd go with MySQL (or Aurora MySQL compatible version)
For data-critical and highly relational solutions I might also consider Postgres (Aurora)
We are planning to migrate an application from MySQL to Cassandra. The one major issue we're seeing is that the application makes extensive use of MyISAM's full text search. What can we use an alternative on cassandra?
There is an implementation of Solr in Cassandra: Solandra.
Solr (pronounced as /soʊlə/,/soʊlər/, SOH-lər) is an open source
enterprise search platform from the Apache Lucene project. Its major
features include powerful full-text search, hit highlighting, faceted
search, dynamic clustering, database integration, and rich document
(e.g., Word, PDF) handling. Providing distributed search and index
replication, Solr is highly scalable.1
You can find some other information here: http://www.datastax.com/docs/datastax_enterprise2.0/search/dse_search_about
Use Elassandra which runs Elasticsearch as a plugin for Apache Cassandra.
Some real example of Elassandra can be found in here
I am new to Ruby and wondering if most people are using the SQLLite db that seems to be the most natural and recommended db to use with Ruby? Or are people using the traditional MySQL db?
What are the benefits/drawbacks of each with Ruby?
Thanks,
Alex
SQLite is used primarily for development purposes only because it is quite simple to setup a database without much frustration, however it is certainly less efficient in terms of concurrency (which is highly likely for web applications) than something like MySQL. So regardless if you use SQLLite in development or not, it is highly advisable to use MySQL (or something equivalent) in production.
For completeness sake, SQLite is also used in "all in one package" software (such as mobile development), in which you can easily bundle a SQLite file with your application.
As stated on SQLite Website:
SQLite is not intended to be an
enterprise database engine. It is not
designed to compete with Oracle or
PostgreSQL.
and
Another way to look at SQLite is this:
SQLite is not designed to replace
Oracle. It is designed to replace
fopen().
In terms of the benefits with Ruby, there really isn't much benefit as libraries/ORMs (i.e. Active Record) really abstract the differences between the two systems to make a consistent access layer in a single wrapper.
SQLITE is cool for desktop applications, mobile applications, and for development :) because it is easy to install and to manage, also it stores all data in one file, which is easy to copy.
But it is a bad choice for production. It doesn't support parallel acces for writing. As bigger file, as slower queries. Problems with scaling. And a number of other problems.
See this topic for more information
https://stackoverflow.com/questions/3630/sqlite-vs-mysql
In rails, you are using ActiveRecord ORM. Many developers are using sqlite adapter for development with ActiveRecord, because it is very easy to setup it.