Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm developing an app for distributors which gives them a list of stores and they note in the app how many products did they sell to any store. This is the main function of my app. There are two choices: firebase realtime database or Cloud Firestore. I need only speed and less pricing. Please tell me how their pricing does work and also which one is faster? Explain shortly please.
Among other factors, the ones mentioned below are really important when choosing a Database Management System are:
Data Model, Data consistency, Data Security, Data Protection, Multi Access and Integration, Efficiency, Usability, Implementation and Service Costs.
From Firebase documentation:
Which database is right for your project?
We recommend Cloud Firestore for most developers starting a new
project. Cloud Firestore offers additional functionality, performance,
and scalability on an infrastructure designed to support more powerful
features in future releases. Expect to see new query types, more
robust security rules, and improvements to performance among the
advanced features planned for Cloud Firestore.
Using Cloud Firestore and Realtime Database
You can use both databases within the same Firebase app or project.
Both NoSQL databases can store the same types of data and the client
libraries work in a similar manner.
Please note that in the link above you shall find detailed information about the differencies between the two.
From medium.com:
Cloud Firestore vs. Firebase Realtime Database
Things they have in common:
They are both easy to integrate into a project with limited setup, and they are compatible with everything else offered by Firebase.
Administrators will be able to see the data through the Firebase
console, which uses the same scheme in both of them. What this means
is that you can scour through the nodes and collections of the top
level to find the data or information that you are looking for.
Beyond that, they do not offer any further level of exploration. If you know the keys and objects that you are looking for, this will be
useful.
Let’s take a look at the differences.
Querying Support — Firestore is more potent in this regard. Locate records that match several field comparisons. Firebase uses a
simplistic data structure, which means that you will only be able to
run queries that search for the field beginning with your query.
Importing and Exporting Data — This is a feature that Firebase provides. It comes in handy when you are migrating data or if team
members who are not developers to make some changes to the data.
Real-time updates — Firebase focuses on real-time updates, which are very useful for handling customers who are using social media or
collaborative apps. It gives developers everything they need to
determine the customers that are active users in real-time.
Costs — The costs of the Realtime Database will go up as you send more data via reading/write operations. The price of the Firestore
database will increase with every API call that you make. However, be
sure to look at the entire cost breakdown before making any decisions.
Pricing
In the following link there are detailed information about Firebase
Realtime Database Pricing and Cloud Firestore Pricing
You may also find this article useful:
Cloud Firestore vs the Realtime Database: Which one do I use?
You should think more carefully the future work load your environment will have. That will give you better ground to evaluate the pricing. In general, I would prefer to use Firestore because it is the new one and it is superior when it comes to scaling the service. It will scale automatically as your user base grows and will not need any sharding in high volumes.
Realtime Database is the Firebase’s first and original cloud-based database. For the mobile apps requiring synced states across clients in realtime, it is an efficient and low-latency solution.
Cloud Firestore is Firebase’s newest flagship database for mobile apps. It is a successor to the Realtime Database with a new and more intuitive data model. Cloud Firestore is richer, faster, and more scalable than the Realtime Database.
You should check the official docs. And get a proper idea between these two. There are things you need to consider before choosing either of them.
According to your goal, both will help you in different ways.
Realtime and offline support, Querying, Writes and transactions, Reliability and Performance, Scalability, Security, Pricing, Data Model, etc.
These are the things you need to consider while choosing either of these
I would like to suggest this link though.
Cloud Firestore vs the Realtime Database: Which one do I use?
Related
Google just released Cloud Firestore, their new Document Database for apps.
I have been reading the documentation but I don't see a lot of differences between Firestore and Firebase DB.
The main point is that Firestore uses documents and collections which allow the easy use of querying compared to Firebase, which is a traditional noSQL database with a JSON base.
I would like to know a bit more about their differences, or usages, or whether Firestore just came to replace Firebase DB?
I wrote an entire blog post all about this very question, and I recommend you check it out (or the official documentation) for a more complete answer.
But if you want the quick(-ish) summary, here it is:
Better querying and more structured data -- While the Realtime Database is just a giant JSON tree, Cloud Firestore is a little more structured. All your data consists of documents (which are basically key-value stores) and collections (which are collections of documents). Documents will also frequently point to subcollections, which contain other documents, which themselves can contain other documents, and so on.
This structured data helps you out in two ways. First, all queries are shallow, meaning that you can request a document without grabbing all the data underneath. This means you can keep your data stored hierarchically in a way that makes more sense to you without having to worry about keeping your database shallow. Second, you have more powerful queries. For instance, you can now query across multiple fields without having to create those "combo" fields that combine (and denormalize) data from other parts of your database. In some cases, Cloud Firestore will just run those queries directly, and in other cases, it will automatically create and maintain indexes for you.
Designed to Scale -- Cloud Firestore will be able to scale better than the Realtime Database. It's important to note that your queries scale to the size of your result set, not your data set. So searching will remain fast no matter how large your data set might become.
Easier manual fetching of data -- Like the Realtime Database, you can set up listeners in Cloud Firestore to stream in changes in real-time. But if you don't want that kind of behavior, and just want a simple "fetch my data" call, Cloud Firestore has that as well, and it's built in as a primary use case. (They're much better than the once calls in Realtime Database-land)
Multi region support -- This basically means more reliability, as your data is shared across multiple data centers at once. But you still have strong consistency, meaning you can always make a query and be assured that you're getting the latest version of your data.
Different pricing model -- While the Realtime Database primarily charges based on storage or network bandwidth, Cloud Firestore primarily charges based on the number of operations you perform. Will this be better, or worse? It depends on your app.
For powering a news app, turn-based multiplayer game, or something like your own version of Stack Overflow, Cloud Firestore will probably look pretty favorable from a pricing standpoint. For something like a real-time group drawing app where you're sending across multiple updates a second to multiple people, it probably will be more expensive than the Realtime Database.
Why you still might want the to use the Realtime Database -- It comes down to a few reasons.
That whole "it'll probably be cheaper for apps that make lots of frequent updates" thing I mentioned previously,
It's been around for a long time and has been battle tested by thousands of apps,
It's got better latency and when you need something with reliably low latency for a real-timey feel, the Realtime Database might work better.
For most new apps, we recommend you check out Cloud Firestore. But if you have an app that's already on the Realtime Database, I don't really recommend switching just for the sake of switching, unless you have a compelling reason to do so.
Reasons to choose Cloud Firestore over Realtime Database
It is an improved version
Firebase database was enough for basic applications. But it was not powerful enough to handle complex requirements. That is why Cloud Firestore is introduced. Here are some major changes.
The basic file structure is improved.
Offline support for the web client.
Supports more advanced querying.
Write and transaction operations are atomic.
Reliability and performance improvements
Scaling will be automatic.
Will be more secure.
Pricing
In Cloud Firestore, rates have lowered even though it charges primarily on operations performed in your database along with bandwidth and storage. You can set a daily spending limit too. Here is the complete details about billing.
Future plans of Google
When they discovered the flaws with Real-time Database, they created another product rather than improving the old one. Even though there are no reliable details revealing their current standings on Real-time Database, it is the time to start thinking that it is likely to be abandoned.
Suggest link from google as well :
Firebase Real-time Database vs FireStore
Extracted from google docs, a small sumamry here:
FireBase Real Time DB is JSON based NO SQL DB, meant for mobile apps, regional, and used typically to store and sync data between users/devices in realtime / extremely low latency.
FireStore is JSON 'like' NOSQL DB meant for high concurrency, global, easily auto scaling persistence, designed for any clients (not only mobile apps) with typical use cases such as asset tracking, real time analytics, building retail product catalogs, social user profile, gaming leaderboards, chat based applications etc.
Cloud Firestore is Firebase's database for mobile app
development. It builds on the successes of the Realtime Database with
a new, more intuitive data model. Cloud Firestore also features
richer, faster queries and scales further than the Realtime Database.
Realtime Database is Firebase's original database. It's an efficient,
low-latency solution for mobile apps that require synced states
across clients in realtime.
To choose between Firebase Realtime database and Cloud firestore based on your application requirements, read official documentation here.
My question might seem a bit naive, but as a beginner iOS developer, I'm starting to think that Core Data is replaceable by firebase realtime database (or firestore in the future). I used both of them in two seperate projects and after activating the offline feature in firebase, I got the same results (that is, the data was saved to the device without the need for an internet connection). I think I read something in the firebase documentation about it not being able to filter and sort at the same time which would probably mean that Core Data can be more convenient for complex queries. It would be great to have some senior developers' views on this subject.
Thanks in advance.
The question is a bit off-topic for SO (IMO) and is (kind of) asking for opinions but it may be worth a high-level answer. I use both platforms daily.
Core Data and Firebase are two unrelated platforms used to (manage and) store data; it's hard to directly compare them without understanding your use case.
CD is a framework used to model objects in your app. It's the 'front end' of data storage, where the 'back end' could be SQL, flat files, plists etc. It's more of a single user concept which stores data locally on the device (it has cloud functionality but that's a different topic).
Firebase on the other hand is a live, event driven, cloud based, multi user capable NoSQL storage. While it offers off-line persistence, that's really for situations where you need to be interacting with data when the device is temporarily disconnected from the internet.
It is not correct that:
firebase documentation about it not being able to filter and sort at
the same time
But, your Firebase structure is dependent on what you want to get out of it - if it's structured correctly, it can be filtered and sorted at the same time in a variety of very powerful (and faaast) ways.
Core Data is really an incredible technology and building relationships between objects is very straight forward and has SQL-like queries for retrieving data.
If you are looking for a database that leverages local storage - go with Core Data or another database that's really strong locally such as Realm, MySql and a number of others.
If you want to have Cloud based, multi-user, event driven storage, Firebase is a very strong contender (Realm is another option as well)
I would suggest building a very simple To-Do type app and use Firebase for storage in one and then build another using Core data. Should only be a couple of hours of work but it will really give you some great basic experience with both - you can make a more informed decision from there.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Using Delphi XE2: I have used AbsoluteDB for years with good success for smallish needs, but it does not scale well to large datasets. I need recommendations for a DB engine for the following conditions:
Large (multi-gigabyte) dataset, few tables with lots of small records. This is industrial-equipment historical data; most tables have new records written once a minute with a device ID, date, time and status; a couple tables have these records w/ a single data point per record, three others have 10 to 28 data points per record depending on the device type. One of the single-data-point tables adds events asynchronously and might have a dozen or more entries per minute. All of this has to be kept available for up to a year. Data is usually accessed by device ID(s) and date window.
Multi-user. A system service retrieves the data from the devices, but the trending display is a separate application and may be on a separate computer.
Fast. Able to pull any 48-hour cluster of data in at most a half-dozen seconds.
Not embedded.
Single-file if possible. Critical that backups and restores can by done programatically. Replication support would be nice but not required.
Can be integrated into our existing InstallAware packages, without user intervention in the install process.
Critical: no per-install licenses. I'm fine with buying per-seat developer licenses, but we're an industrial-equipment company, not a software company - we're not set up for keeping track of that sort of thing.
Thanks in advance!
I would use
either PostgreSQL (more proven than MySQL for such huge data)
or MongoDB
The main criteria is what you would do with the data. And you did not say much about that. Would you do individual queries by data point? Would you need to do aggregates (sum/average...) over data points per type? If "Data is usually accessed by device ID(s) and date window", then I would perhaps not store the data in individual rows, one row per data point, but gather data within "aggregates", i.e. objects or arrays stored in a "document" column.
You may store those aggregates as BLOB, but it may be not efficient. Both PostgreSQL and MongoDB have powerful objects and arrays functions, including indexes within the documents.
Don't start from the DB, but start from your logic: which data are you gathering? how is it acquired? how is it later on accessed? Then design high level objects, and let your DB store your objects in an efficient way.
Also consider the CQRS pattern: it is a good idea to store your data in several places, in several layouts, and make a clear distinction between writes (Commands) and reads (Queries). For instance, you may send all individual data points in a database, but gather the information, in a ready-to-use form, in other databases. Don't hesitate to duplicate the data! Don't rely on a single-database-centric approach! This is IMHO the key for fast queries - and what all BigData companies do.
Our Open Source mORMot framework is ideal for such process. I'm currently working on a project gathering information in real time from thousands of remote devices connected via Internet (alarm panels, in fact), then consolidating this data in a farm of servers. We use SQLite3 for local storage on each node (up to some GB), and consolidate the data in MongoDB servers. All the logic is written in high-level Delphi objects, and the framework does all the need plumbing (including real-time replication, and callbacks).
I am building an rails application which will have huge amount of user and their activities and tasks and dynamic attributes. Currently I am using postgresql but I know it is not a good choice this kind of application.
I am a confused between Graph databases and 'Nosql databases` which one to choose.
A graph database is a NoSQL database, as is a document database, column-store database, and a key/value database. Regarding which one to choose: Unfortunately that cannot be answered so simply, as a lot will depend on your specific application.
But... why choose one? Each type of NoSQL data store has its specific advantages. You can build a system based on multiple data stores, each one used to its specific advantage(s). This concept is known as polyglot persistence.
The Microsoft Patterns & Practices team published guidance around this very topic, and I'd suggest reading through it. You can also check out the book NoSQL Distilled which also goes into this topic and the specifics of each data store classification.
If you want to see an example of an app built on several data stores, check out Cloud Ninja Polyglot Persistence. Members of my team (including myself) got together and built this as a learning/training exercise.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
My company has this Huge Database that gets fed with (many) events from multiple sources, for monitoring and reporting purposes. So far, every new dashboard or graphic from the data is a new Rails app with extra tables in the Huge Database and full access to the database contents.
Lately, there has been an idea floating around of having external (as in, not our company but sister companies) clients to our data, and it has been decided we should expose a read-only RESTful API to consult our data.
My point is - should we use an API for our own projects too? Is it overkill to access a RESTful API, even for "local" projects, instead of direct access to the database? I think it would pay off in terms of unifying our team's access to the data - but is it worth the extra round-trip? And can a RESTful API keep up with the demands of running 20 or so queries per second and exposing the results via JSON?
Thanks for any input!
I think there's a lot to be said for consistency. If you're providing an API for your clients, it seems to me that by using the same API you'll understand it better wrt. supporting it for your clients, you'll be testing it regularly (beyond your regression tests), and you're sending a message that it's good enough for you to use, so it should be fine for your clients.
By hiding everything behind the API, you're at liberty to change the database representations and not have to change both API interface code (to present the data via the API) and the database access code in your in-house applications. You'd only change the former.
Finally, such performance questions can really only be addressed by trying it and measuring. Perhaps it's worth knocking together a prototype API system and studying it under load ?
I would definitely go down the API route. This presents an easy to maintain interface to ALL the applications that will talk to your application, including validation etc. Sure you can ensure database integrity with column restrictions and stored procedures, but why maintain that as well?
Don't forget - you can also cache the API calls in the file system, memory, or using memcached (or any other service). Where datasets have not changed (check with updated_at or etags) you can simply return cached versions for tremendous speed improvements. The addition of etags in a recent application I developed saw HTML load time go from 1.6 seconds to 60 ms.
Off topic: An idea I have been toying with is dynamically loading API versions depending on the request. Something like this would give you the ability to dramatically alter the API while maintaining backwards compatibility. Since the different versions are in separate files it would be simple to maintain them separately.
Also if you use the Api internally then you should be able to reduce the amount of code you are having to maintain as you will just be maintaining the API and not the API and your own internal methods for accessing the data.
I've been thinking about the same thing for a project I'm about to start, whether I should build my Rails app from the ground up as a client of the API or not. I agree with the advantages already mentioned here, which I'll recap and add to:
Better API design: You become a user of your API, so it will be a lot more polished when you decided to open it;
Database independence: with reduced coupling, you could later switch from an RDBMS to a Document Store without changing as much;
Comparable performance: Performance can be addressed with HTTP caching (although I'd like to see some numbers comparing both).
On top of that, you also get:
Better testability: your whole business logic is black-box testable with basic HTTP resquest/response. Headless browsers / Selenium become responsible only for application-specific behavior;
Front-end independence: you not only become free to change database representation, you become free to change your whole front-end, from vanilla Rails-with-HTML-and-page-reloads, to sprinkled-Ajax, to full-blown pure javascript (e.g. with GWT), all sharing the same back-end.
Criticism
One problem I originally saw with this approach was that it would make me lose all the amenities and flexibilities that ActiveRecord provides, with associations, named_scopes and all. But using the API through ActveResource brings a lot of the good stuff back, and it seems like you can also have named_scopes. Not sure about associations.
More Criticism, please
We've been all singing the glories of this approach but, even though an answer has already been picked, I'd like to hear from other people what possible problems this approach might bring, and why we shouldn't use it.