Has anyone used Netflix Conductor with a completely different backend . We are thinking to plug in the Conductor with Azure Cosmos DB as backend .
Conductor by design has a pluggable architecture which means as long as you implement the storage interfaces you can use any data store. In the OSS there is community contributions for MySQL and other stores.
Related
Hello I am trying to implement High Availibity back-end for the freeradius server. I want to have an in memory database with an active-active architecture. I found that redis provide the geo-distribution but it's not open-source it's a payable feature I also found that coushbase provide you with such a thing but it's also in the entreprise edition.
Is there any solution that I could implement an open-source, active-active and in-memory back-end. I can use both sql and NoSql databases. I only need HA and processing speed.
Thank you.
I have previous experience in using Ethereum and Solidity, but now I want to try writing smart contracts for Hyperledger.
I have few considerations:
First one is regarding supported databases. According to their documentation (http://hyperledger-fabric.readthedocs.io/en/latest/ledger.html) they use LevelDB for storing contract data and CouchDB support is still in beta. Does anyone have any experience using CouchDB in Hyperledger?
Second, I see that Go is mostly used for the specification of smart contracts, but they have support for Java too. Is Java still in beta too, and is there support for any other programming language?
Also, what operating system do you suggest for production server running Hyperledger?
Thank you for the answers.
Is Java still in beta too, and is there support for any other
programming language?
Hyperledger V1.0 doesn't support Java Chaincode.
There will be support for it in the future.
You can ask around in https://chat.hyperledger.org/channel/fabric for ETAs.
There is also a work in progress to have node.js support.
Also, what operating system do you suggest for production server
running Hyperledger?
Ubuntu 16.04 LTS works well
Does anyone have any experience using CouchDB in Hyperledger?
Yes, CouchDB works well if your data is modeled as JSON and you would like to query the content of the data. The default goleveldb state database only supports key-based queries.
You should take a look at Hyperleger Composer that helps you create blockchain applications on Hyperledger Fabric quite easy. (It works better with Ubuntu).
It has is own Modeling Language.
Hyperledger initially was build using Go language.
the aim of the hyperledger team is to support as many languages as possible. currently the hyperledger composer( tool for developing blockchain application) supports javascript for defining the assets, transactions and chaincode.
the transactions log, state data and backed by Level DB and Couch DB
Note :
LevelDB and CouchDB are fully integrated in fabric framework,
currently you can't replace them with other database
Chaincode runs in a secured Docker container, the chaincode (aka smart-contract)can be programmed in Go,Node,Java currently Go is stable and fully supported language.
considering the operating system i have tested the fabric network running on Microsoft Azure platform where created a image of ubuntu 16.04 and installed Fabric framework.till now got no issue on it.
I have a distributed monitoring system that collects and gathers monitoring data like CPU utilization, database performance metrics, network performance into a backend store. Other applications need to consume these data like real-time calculating(for a resource scheduler) , for system monitoring(to system administrator using monitoring dashboard), for historical analytic(to operation and analyzer program to modeling the resource using pattern for future capacity planning and business system activity analysis).
The dataset size is about 1.2 billion entries in the data store for 9 months. (all in OpenTSDB like format)
Previously I used an Elasticsearch cluster as the backend data store solution and decide to find a better one.
I am looking at Couchbase or VoltDB cluster but still in investigation stage so need some input from here who has the similar experience.
Major questions are as below:
Which backend store solution is good for my scenario? (Couchbase or VoltDB)?
I have to rewrite my data aggregator code (which is in golang). Couchbase provide a good golang SDK client but VoltDB's go driver is only in community level with limited function. So are there any better implementation to communicate with voltdb in golang?
Any suggestion or best practice on it?
There isn't too much in the way of usage patterns here, but it sounds like the kind of app people use VoltDB for.
As for the Golang client, we'd love some feedback as to how to make it more suitable if it's specifically missing something you need. You can also use the HTTP/JSON query interface from any language, including Golang. More info on that here:
http://docs.voltdb.com/UsingVoltDB/ProgLangJson.php
If you would like to leverage your existing model, take a look at Axibase Time-Series Database. It supports both tcollector network and http protocols. Rule engine and visualization are built-in.
The fact that ATSD is based on HBase may be an asset or a liability depending on your prior experience with it :)
URL to tcollector integation: http://axibase.com/products/axibase-time-series-database/writing-data/tcollector/
Disclosure: I work for the company developing ATSD.
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
MongoDB vs Firebase
What are some quantitative advantages of using Firebase over MongoDB? (not opinions)
I know that Firebase is a cloud-based service with its own API, but I feel like Mongo may give me greater control in the long run.
Firebase is a real-time engine with backward connectivity. I.e. you might build a cross-platform app where clients subscribe to events on specific data and server actively informs clients about changes
The data layer is hosted for you. Mind that it is highly scalable. It's a nice kickstarter solution. Including auth management
Geo-Fire. Real-time geo coordinates solution.
Evident drawbacks of Firebase are:
You have to pay for it as soon as you start growing
You can't host datalayer (if owning data is critical or you develop an app for some separated subnet)
EDIT: here is a nice article how to replace Firebase in your app with Node.js+MongoDb. It shows how much work you would have to do on your own, and explains, IMHO, why a startup (small app) should begin with Firebase (if real-time updates to clients are required) and proceed with MongoDb (in any case self-written solution) if the project keeps evolving
EDIT 2: after being acquired by Google Firebase now offers various perks on top of its basic features which you would struggle to build on your own:
For development
Cloud Messaging: Deliver and receive messages across platforms reliably
File Storage: Easy file storage (including iOS)
Hosting: deliver static files from Firebase's servers (Included in Free plan)
Crash Reporting: Not a full logging service, but crucial help
For growth
Remote Config: Customize your app on the fly: suitable for A/B testing
Dynamic Links: Send users to the right place inside your app
Notifications: Engage with users at the right moment
Apples and oranges. Firebase is a Backend-as-a-Service containing identity management, realtime data views and a document database. It runs in the cloud.
MongoDB on the other hand is a full fledged database with a rich query language. In principle it runs on your own machine, but there are cloud providers.
If you are looking for the database component only MongoDB is much more mature and feature-rich.
Firebase is designed for real-time updates. It easily integrates with angular. Both are NoSQL databases. MongoDB can also do this with Angular through Socket.io integration. Meteor.js also makes use of MongoDB with an open socket connection for real-time updates.
MongoDB can be run locally, or hosted on many different cloud based providers. Firebase, in my opinion is great for smaller apps, very quick to get up and running. MongoDB is ideal for more robust larger apps, real-time integration is possible but it takes a bit more work.
After using Firebase a considerable amount I've come to find something.
If you intend to use it for large, real time apps, it isn't the best choice. It has its own wide array of problems including a bad error handling system and limitations. You will spend significant time trying to understand Firebase and it's kinks. It's also quite easy for a project to become a monolithic thing that goes out of control. MongoDB is a much better choice as far as a backend for a large app goes.
However, if you need to make a small app or quickly prototype something, Firebase is a great choice. It'll be incredibly easy way to hit the ground running.
I will answer this question in terms of AngularFire, Firebase's library for Angular.
Tl;dr: superpowers. :-)
AngularFire's three-way data binding. Angular binds the view and the $scope, i.e., what your users do in the view automagically updates in the local variables, and when your JavaScript updates a local variable the view automagically updates. With Firebase the cloud database also updates automagically. You don't need to write $http.get or $http.put requests, the data just updates.
Five-way data binding, and seven-way, nine-way, etc. I made a tic-tac-toe game using AngularFire. Two players can play together, with the two views updating the two $scopes and the cloud database. You could make a game with three or more players, all sharing one Firebase database.
AngularFire's OAuth2 library makes authorization easy with Facebook, GitHub, Google, Twitter, tokens, and passwords.
Double security. You can set up your Angular routes to require authorization, and set up rules in Firebase about who can read and write data.
There's no back end. You don't need to make a server with Node and Express. Running your own server can be a lot of work, require knowing about security, require that someone do something if the server goes down, etc.
Fast. If your server is in San Francisco and the client is in San Jose, fine. But for a client in Bangalore connecting to your server will be slower. Firebase is deployed around the world for fast connections everywhere.
Firebase is a suite of features .
Realtime Database
Hosting
Authentication
Storage
Cloud Messaging
Remote Config
Test Lab
Crash Reporting
Notifications
App Indexing
Dynamic Links
Invites
AdWords
AdMob
I believe you are trying to compare Firebase Realtime Database with Mongo DB .
Firebase Realtime Database stores data as JSON format and syncs to all updates of the data to all clients listening to the data . It abstracts you from all complexity that is needed to setup and scale any database . I will not recommend firebase where you have lot of complex scenarios where aggregation of data is needed .(Queries that need SUM/AVERAGE kind of stuff ) . Though this is recently achievable using Firebase functions . Modeling data in Firebase is tricky . But it is the best way to get you started instantaneously .
MongoDB is a database. This give you lot of powerful features. But MongoDB when installed in any platform you need to manage it by yourself .
When i try to choose between Firebase or MongoDB(or any DB ) . I try to answer the following .
Are there many aggregation queries that gets executed .(Like in
case of reporting tool or BI tool ) . If Yes dont go for Firebase
Do i need to perform lot of transaction . (If yes then i would
not like to go with firebase) (Tranactions are somewhat easy though
after introduction of functions but that is also a overhead if lot of
transactions needs to be maintained)
What timeline do i have to get things up and running .(Firebase
is very easy to setup and integrate ).
Do i have expertise to scale up the DB and trouble shoot DB related
stuffs . (Firebase is more like SAAS so no need to worry about scaleability)
In my experience, working with Firebase is a huge advantage if you are trying to do user management, database, messaging sort of app since all of these features are already well integrated.
Like others have said, if you're just focused on the database/querying aspect, stick to mongo.
Firebase provides some good features like real time change reflection , easy integration of authentication mechanism , and lots of other built-in features for rapid web development.
Firebase, really makes Web development so simple that never exists. Firebase database is a fork of MongoDB.
What's the advantage of using Firebase over MongoDB?
You can take advantage of all built-in features of Firebase over MongoDB.
I develop a commercial Asp.Net MVC Web Application. The application is standard, runs on IIS Web Server and utilizes SQL Server database. Our business model is such that we deploy our application on-site in our customers’ Intranet or data center. That is, for each such customer (account) we supply the complete setup, usually installed in a dedicated standalone server. Each such account has its own private content, users, configurations and so on.
We wish to expand and offer our service on the WWW (public Internet). After some research, I’ve chosen Microsoft’s Azure cloud platform to host our application. With some minor efforts (mainly teaching the application to work with Azure’s File Storage using blobs) I’ve managed to fully deploy to the cloud, using three cloud services: Web Site, Data base and File Storage.
Please note that I employ the same code base for the two deployment types (Intranet and Cloud), by using different configurations for Debug, Release – Intranet, Staging – Azure, Production – Azure.
However, the application (as is it written now) can serve only a single customer account, while I need our cloud version to serve numerous accounts (hopefully a lot ;) … each with its own private data set.
Question: which of the following strategies should I employ here?
Change the application so it will support multiple accounts. This means changes both in the data model (adding an Account entity in the data layer, bind it to all content types, etc.) and in the business logic.
Create for each Account its own site on the cloud (web site + data base + file storage services). This means deploying several times the same application to different Azure services.
It’s obvious that the amount of development needed for the 1st approach here is very large as is the risk in stability of the system, while the 2nd approach requires much less effort.
However, im not clear about how to manage a set of many identical services (applications) each serving a different customer account. I’ve started looking for some tools to help me here (e.g. Red Gate), and would love to hear of more.
Another question is the cost – is such a solution, using many cloud services instead of only few, more costly that the more standard “one application for all accounts” approach.
thanx,
I would recommend (1). It is a higher short term cost in terms of development effort, but will be better for two reasons long term:
Cheaper. The costs will go up quite a bit by adding more cloud services. I suppose you could pass this cost on to your client though?
It does become harder to manage releases across many clients.
I would say you can either spend your time refactoring existing code you know - or - you can learn how to do dev ops against Azure to manage releases. Probably easier to refactor what you know instead of learn something new.
As a note there are many great SDKs to automate deployments, scaling cloud services, etc.
Found some good reading about this issue:
MSDN: Developing Multi-tenant Applications for the Cloud, 3rd Edition
Provides good comparison between the two approaches:
Single Instance, Multi-tenant (my 1st option)
Multi Instance, Single-tenant (my 2nd option)
As it looks i will go with the Multi-tenant approach. All things considered it looks like it will require less development effort and will need less effort in maintenance. Also, my expertise lies in application development and less in system administration (which is required for truly implementing multi-instance solution).
Other reasons: there's a need to share some of the content between accounts (tenants), and this will be more easily achieved when using a single database. Also, there are future plans for the product which can utilize this solution.
Segregation of data will be done (high level):
File storage (blobs): use a separate container for each tenant (account).
Database: use tenant unique key to associate content to tenant
Cahce: use tenant unique key to generate cache keys for cached data items.
Scalability: it is easier using one instance to simply scale up its capabilities, or even move the Web Site to a dedicated virtual machine. In the future can also enhance the system to a Multi-instance, Multi-tenant structure, creating new separate instances for large tenants.