My app is growing very fast, and we have used Parse.com as the main database.
We want to create a web version of this to work together with the app for iOS and Android.
The only limitation that we know from Parse.com is that the queries max limit is 1000, so after it you need to create a function to do more queries.
So talking about a very large database, performance on server-side, Users doing queries using 3g network and scalability, is a good way move it to mysql?
Not considering time and cost.
Only talking about performance, scalability and queries to work with Android, iOS and web.
Thank you
In terms of scalability I guess you really need to worry about that if you are managing your own servers. Worse case, you go with a professional hosting service but use VPS.
Parse uses mongoDB which is entirely different than MySQL. The 1000 limit should really be an issue regardless of what database you use because you should be structuring your app that you don't grab anywhere near 1000 items at once. That is where lazy loading comes into play.
Parse is a REST API. This means you're using HTTP requests to get information. You will need to write an API or find an open source option to put on your server. You need to make sure that your code runs efficiently so you can get results fast and put as little strain as possible on your servers.
Another thing is to try and prevent having 1000 queries. If there's a way where you can download data that can be reused in the app instead of re-downloading it each time then do it. Less strain on servers, quick response, and little data going back and forth.
That's really all I have to offer.
Not sure if this would help you, but I'm moving stuff out as well, but you are comparing two different databases to each other. I'm moving my data to Cassandra or MongoDB, that's because the data is key value. As for mysql, I hope you keep in mind, a lot of companies use it for large scale problems and they run it fine. I hope this helps.
Related
I want to create an Android/iOS tablet app that will visualize data from a number of desktop apps that have the same function (facilitating orienteering events) but may be very different in their construction. The idea I have is that when anything changes in the desktop server database, the change is communicated to my tablet app.
Now, I don't know what would be a good form of communication between the server and the app (JSON?), but I think that before anyone would want to consider modifying their desktop app to be able to share data with mine, my app needs to actually work.
So I'm looking to write my first line of code, but I think before I do that, I need to decide on a database. In the tablet app, the user would only be performing read operations. The data itself would be small (short strings and some ints/longs) and structured and work well with a relational DB. Assuming the server communicates all updates immediately, there could be an update on average every 5 seconds for a normal event.
Considering how you described the problem, the data doesn't seem too complex or big; This is more of a "what do you prefer to work with" instead of "what do you need".
JSON in this case is a good format for your data, and if you like working with it, then that's a good solution.
If you want to use JSON format, MongoDB might be the best choice. Easy to learn, big community, pretty advanced and complete.
I am a new guy to full stack web application development. I want to design a web application which has data stored in say back end databases. Now I want to design a desktop web client as well as android application which will be able to fetch data from back end. So how do I need to start? What APIs can be used or how can I expose data from same back end to multiple clients?
Also I want to handle massive amount of request. How to design such a system? What to use in back end to store data and handle requests efficiently.
Any video / document / reference containing useful information will be much appreciated.
Wow, you have a whole forest of questions to settle. You are going to need to go do your own research on such things as algorithms and data flow for your application before you can make any reasonable choice of platform. Here are a couple of basic ideas to get you going: 1) look at Java and Node.js. There are lots of other possible platforms but chances are you will end up using one of those two. Try to think about what the actual code you will generate in each of those will look like. A little or a lot? 2) Just store your data in files, most probably using JSON. Maybe you will end up doing something more fancy after you figure out where you are going with your project, but you will be surprised how well the simple file-based solution will scale.
When you have done a bunch more research, and maybe even coded up a few ideas on your platform of choice, then come back and massively edit your question. Only then will specific suggestions for tool choices be possible.
So I am in need of some assistance in trying to determine what I am going to need in order to accomplish a task.
Plain and simple...I am looking at accessing multiple databases some of which may contain over 10,000 records via Android. From what I have seen web services that return JSON is the way to go for something of this nature, but I don't think that fully answers my question or know if this is the preferred way to go about this.
Digging a bit deeper...I have a few apps on the market now, but this will be my first attempt at an enterprise style app, and I have accessed public web services with a lot smaller footprint than what this is going to be. I have little to no experience within the realm of server/network administration which is where I am getting tripped up. This is from the ground up and I have to ability to obtain almost any resources I need to complete this task.
It appears that there is a SQL Server 2008 on the back end if that helps. If I need to provide further details let me know. I am looking at a solution that will handle organizational growth, scalability, authentication and ease of user...so keep that in mind too.
So what is the best practice/preferred method for doing an enterprise application with a substantial data set? What are the big dogs doing, and how? Both on the client side and server side. I am trying not to "screw the pooch" out of the gates on this, and this is one of those measure twice and cut once situations which is why I am trying to garner plenty of input and assistance.
Thanks in advance!
If you don't have an API/service yet, you need to write one on top of your database.
I can think of two approaches, depending upon your use case.
Paging: Setup an API that supports paging, and show the results page by page. The user can't possibly view 10000 records in one go.
Search and suggest: Try creating a suggestion list, when the user starts typing out something. Fetch results that start with the initial characters entered. However, the API should limit the results to a comfortable number, so that you don't have to parse a lot.
Depending on your use case, you could try one of these.
I'm working on an Android app that consumes a web service that has the potential to return quite a lot of data. The web service is also goingto be built by my team, and we're looking into ways of transferring data to the client with the least amount of load. We've looked into REST and SOAP, and can't decide between the two. Would JSON be a good alternative? We might need to fetch quite a lot of data in some use cases.
We'd really rather not use SOAP, if can avoid it. The emphasis is on reducing the work needed to be done on the Android system as much as possible.
Could anybody please help us out? As far as technology scope is concerned, we have full freedom of choice as long as we stay within the JAVA umbrella.
Thanks in advance.
EDIT: Not sure how to add comments, so I'll do it here(I read the FAQs, but couldn't find the necessary section)
Hi,
Let me start by apologising for my vague problem statement, I was actually a bit rushed when I posted the query. Anyway, to answer your questions, by "a lot of data", I mean that there are going to be ba few large requests(2-3, depending on the use case) that MIGHT return a lot of data, e.g. if I search using the entity name(complete or partial), the result, which is going to be textual data only, would be considerably less than if the serach was made with country as a search parameter, in which case it might return several hundred separate results. One particular search parameter has the potential to return a few thousand rows of data. What we can control is the amount of data in each row(so to speak) returned. Currently, we're attempting to reduce the items to display per row(we're attempting to keep it below 5). It's a business decision, I'm afraid, so if we're stuck with the current scenario of 12 items per row, we need to be prepared for that as well, I'm afraid.
What you just said was the equivalent of "i cannot decide between unleaded and 15" tyres".
Restful web services tend to be lighter than soap but there are use cases for both. They are both technologies used to deliver service orientated architecture. For you small description I would use rest although with more detail there may be a case for soap. You say a lot of data but does this mean many small requests or a few large ones?
Your restful web service may return a variety of data formats such as xml, yaml and json. Json's syntax makes it lighter than xml so that could be a good choice. Examples of this sort of setup include Facebook's open graph api and drupal's services module.
I'm working on an Android application which is fetching data from internet among other things. Actually, the project was started by someone else which is not here anymore,
and now that I have to turn it into a light client application and implement the server side (in Java), I'm wondering what would be the best tools/patterns to use to fit my needs.
Let's say I have to deal with several models (class representing a category) of objects which all inherits from one class : they have common attributes (such as name, attache thumbnail...) but specific properties too.
Because of this,you can understand that I can't afford to manage one specific table to map each single class.
However, I still want to be able to cache my objects somewhere in the Android device to populate the views of the application when working in offline mode.
Currently, the solution used by the previous developer was to store data directly into a TEXT field in the SQLIite database, as serialized objets.
This should be ok on the server side but I've read that the usual Java serializaton was very slow on the Android platform, although it is not really noticeable now because I work with around ~50 objects, I was looking for more performant alternatives for the future.
I've came across the JSON solution which can easily handle complex structures and Jackson library seems very interesting with its simplified data binding to POJO objects and its well-known performance.
But then, how should I store my Json objects ?
Is it possible to keep a json string in a TEXT field of a SQlite table ?
Or should I rather store them as .json file for each object ?
Which one is the more efficient to retrieve later lot of data?
Plus, I was thinking that JSON would be a very good exchange format between the Android client application and my server whould is in charge of processing the information from internet third-parties apis and exposing this data with webservices. (rather than trying to implement some RMI-like solution)
Is using the usual Apache HTTPClient enough on Android to communicate with the server?
For those who successfully developped client-server application (which seems very common to me) is this a good approach for Android ?
It seems to me that with mobile platforms, you can't really use the approach that you've learned for more classic J2EE app and such...
Any advice would be greatly appreciated because I'm a student and Android beginner who really want to improve her mobile development skills !
Thanks :)
That's open to discussion, so SO is probably not the best place to ask. In general, before declaring something is too slow (or fast), measure, compare and pick the one that works best for you. Yes, you can save JSON in a DB, an it will generally be faster than having separate files on the FS. But, again, benchmark and compare.
BTW, most J2EE 'approaches' (patterns) are overkill for any platform, let alone mobile.