Invite Your Boss to the Business Track at MongoNYC

Meghan Gill
May 23, 2013 | Updated: May 22, 2015
#mongodb days

MongoDB Days have traditionally been focused on the developer community, with lots of technical talks on application design, deployment best practices, and ops war stories. MongoNYC will carry on the tradition of including many deep technical sessions, with talks from the 10gen staff on the latest features in 2.4, as well as presentations from MongoDB community members on their experiences deploying MongoDB in real-world scenarios.

But this year at MongoNYC, we’re introducing a new track aimed at IT managers, directors, and C-level executives who aren’t knee-deep in code. The business track will include case studies from 10gen customers with a focus on the business benefits of using MongoDB, such as reduced cost, new revenue streams and competitive advantaged. We’ll look at the steps enterprises take to adopt NoSQL and open-source technologies, and how you can learn from their experiences.

Here are some of the talks included on the business track at MongoDB NYC:

  • Telefonica explains how it reduced development time by over 80% from its previous Oracle implementation, building a rich, globally available user data management system.

  • ADP describes how it built a mobile app in just a few months to let customers view payroll and benefits information on their devices of choice, differentiating ADP from stale on-premise solutions.

  • Criteo shows how it supported 200,000% growth over five years and global expansion to 7 continents migrating away from SQL Server to MongoDB for its core business, improving online shopping by bringing the performance of search to display advertisers.

  • And more.

So if you’re a developer or DBA who loves MongoDB, but you’ve only been able to use it for small or side projects, consider inviting your boss to MongoNYC this year. Or, attend the business track and return to the office as an advocate for the business advantages of MongoDB in your enterprise.

For more information on MongoDB NYC or to register, please visit http://www.10gen.com/events/mongonyc-2013. Tomorrow is your last chance to register at the early bird rate, which is only $75. Looking forward to seeing you there.

← Previous

New Geo Features in MongoDB 2.4

Motivation Geometric processing as a field of study has many applications, and has resulted in lots of research, and powerful tools. Many modern web applications have location based components, and require a data storage engines capable of managing geometric information. Typically this requires the introduction of an additional storage engine into your infrastructure, which can be a time consuming and expensive operation. MongoDB has a set of geometric storage and search features . The MongoDB 2.4 release brought several improvements to MongoDB’s existing geo capabilities and the introduction of the 2dsphere index . The primary conceptual difference (though there are also many functional differences) between the 2d and 2dsphere indexes, is the type of coordinate system that they consider. Planar coordinate systems are useful for certain applications, and can serve as a simplifying approximation of spherical coordinates. As you consider larger geometries, or consider geometries near the meridians and poles however, the requirement to use proper spherical coordinates becomes important. In addition to this major conceptional difference, there are also significant functional differences, which are outlined in some depth in the Geospatial Indexes and Queries section of the MongoDB documentation. This post will discuss the new features that have been added in the 2.4 release. What’s New Storing non-point geometries Unlike the 2d index, which only allowed the storage of points, the 2dsphere index allows the storage and querying of points, lines, and polygons. To support the storage of different geometries, instead of introducing a proprietary format, MongoDB conforms to the GeoJSON standard. GeoJSON is a collaborative community project that produced a specification for encoding entities in JSON. It has garnered significant support, including the OpenLayers project , PostGIS , and has growing language support for python and ruby . Here are a few simple examples of GeoJSON embedded documents: A BSON Document with a GeoJSON Point embedded in the geo field: { geo: { type: “Point”, coordinates: [100.0, 0.0] } } A BSON Document with a GeoJSON LineString embedded in the geo field: { geo: { type: “LineString”, coordinates: [ [100.0, 0.0], [101.0, 1.0] ] } } A BSON Document with a GeoJSON Polygon embedded in the geo field: { geo: { type: “Polygon”, coordinates: [ [ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0], [100.0, 1.0], [100.0, 0.0] ] ] } } Note: A GeoJSON Polygon’s coordinates are an array of arrays of point specifications. Each array of point specifications should have the same starting and ending point to form a closed loop. The first array of point specifications defines the polygon’s exterior geometry, and each subsequent array of point specifications defines a “hole” in the polygon. Polygons should be non self-intersecting, and holes should be fully contained by the polygon. Inclusion searches on a sphere The new $geoWithin operator, which takes a Polygon geometry as a specifier, returns any geometries of any type that are fully contained within the polygon. It will work well without any index, but must look at every document in the collection to do so. Intersecting geometries on a sphere The new $geoIntersects operator, which takes any geometry as a specifier, returns any geometries that have a non-empty intersection with the specifier. $geoIntersects also works well without an index, and must also look at each document in the collection. Better support for compound indexes The 2d index can only be used in a compound index if 1. it is the first field, 2. there are exactly two fields in the compound index, and 3. if the second field isn’t a 2d index. 2dsphere indexes aren’t limited in this way, which allows us to pre-filter based on a non-geo field - which is often more efficient. Consider the following queries: Find me Hot Dog Stands in New York state i.e. use a compound index: (business_type, location). Find me geometries in New York state that are Hot Dog stands i.e. use the compound index: (location, business_type) The first query will be much more efficient than the second, because business_type is a simple text field, and greatly reduces the set of geometries to search. Additionally, we can have multiple 2dsphere indexes in the same compound index. This allows queries like: “Find routes with a start location within 50 miles from JFK, and an end location within 100 miles of YYC”. How it Works Everything starts when you insert a geometry into a 2dsphere index. We use the open source s2  C++ library  from google to select a minimal set of cells that fully cover a geometry. This set of grid cells is called a covering, and the size of the cells is dynamic (between 500m and 100km on a side) based upon the size of the polygon being covered. fig 3 - A very low granularity covering of the entire United Kingdom fig 4 - A fairly granular covering of the A4 around Trafalgar Square.  Each cell in these coverings is now added to a standard B-tree index, with a key that is easily calculable by the location on surface of the sphere - more granular(smaller) cells will have the same prefix as a larger cell that occupies the same area of the surface of the sphere. Intersection & Within searches Finding geometries that may be intersecting or within a search polygon becomes as easy as generating a covering for the search specifier, and for each cell in that covering, query the B-tree for any geometries that interact with these cells. Once the list of possibly interacting geometries has been retrieved from the index, each geometry in checked in turn to see if it should be included in the result set. Near searches The near search provided by the $near operator is implemented by doing $within searches on concentrically growing donuts (circular polygons with with circular holes).   We encourage user feedback and testing on these new Geo features and are excited to see what the community builds. Map images ⓒ  OpenStreetMap  contributors, licensed under the Creative  Commons Attribution-ShareAlike 2.0  license (CC-BY-SA).  Map data ⓒ  OpenStreetMap  contributors, licensed under the  Open Data Commons Open Database License  (ODbL).

May 21, 2013
Next →

4 Critical Features for a Modern Payments System

The business systems of many traditional banks rely on solutions that are decades old. These systems, which are built on outdated, inflexible relational databases, prevent traditional banks from competing with industry disruptors and those already adopting more modern approaches. Such outdated systems are ill-equipped to handle one of the core offerings that customers expect from banks today — instantaneous, cashless, digital payments . The relational database management systems (RDBMSes) at the core of these applications require breaking data structures into a complex web of tables. Originally, this tabular approach was necessary to minimize memory and storage footprints. But as hardware has become cheaper and more powerful, these advantages have also become less relevant. Instead, the complexity of this model results in data management and programmatic access issues. In this article, we’ll look at how a document database can simplify complexity and provide the scalability, performance, and other features required in modern business applications. Document model To stay competitive, many financial institutions will need to update their foundational data architecture and introduce a data platform that enables a flexible, real-time, and enriched customer experience. Without this, new apps and other services won’t be able to deliver significant value to the business. A document model eliminates the need for an intricate web of related tables. Adding new data to a document is relatively easy and quick since it can be done without the usually lengthy reorganization that RDBMSes require. What makes a document database different from a relational database? Intuitive data model simplifies and accelerates development work. Flexible schema allows modification of fields at any time, without disruptive migrations. Expressive query language and rich indexing enhance query flexibility. Universal JSON standard lets you structure data to meet application requirements. Distributed approach improves resiliency and enables global scalability. With a document database, there is no need for complicated multi-level joins for business objects, such as a bill or even a complex financial derivative, which often require object-relational mapping with complex stored procedures. Such stored procedures, which are written in custom languages, not only increase the cognitive load on developers but also are fiendishly hard to test. Missing automated tests present a major impediment to the adoption of agile software development methods. Required features Let’s look at four critical features that modern applications require for a successful overhaul of payment systems and how MongoDB can help address those needs. 1. Scalability Modern applications must operate at scales that were unthinkable just a few years ago, in relation to both transaction volume and to the number of development and test environments needed to support rapid development. Evolving consumer trends have also put higher demands on payment systems. Not only has the number of transactions increased, but the responsive experiences that customers expect have increased the query load, and data volumes are growing super-linear. The fully transactional RDBMS model is ill suited to support this level of performance and scale. Consequently, most organizations have created a plethora of caching layers, data warehouses, and aggregation and consolidation layers that create complexity, consume valuable developer time and cognitive load, and increase costs. To work efficiently, developers also need to be able to quickly create and tear down development and test environments, and this is only possible by leveraging the cloud. Traditional RDBMSes, however, are ill suited for cloud deployment. They are very sensitive to network latency, as business objects spread across multiple tables can only be retrieved through multiple sequential queries. MongoDB provides the scalability and performance that modern applications require. MongoDB’s developer data platform also ensures that the same data is available for use with other frequent consumption patterns like time series and full-text search . Thus, there is no need for custom replication code between the operational and analytical datastore. 2. Resiliency Many existing payment platforms were designed and architected when networking was expensive and slow. They depend on high-quality hardware with low redundancy for resilience. Not only is this approach very expensive, but the resiliency of a distributed system can never be reached through redundancy. At the core of MongoDB’s developer data platform is MongoDB Atlas , the most advanced cloud database service on the market. MongoDB Atlas can run in any cloud, or even across multiple clouds, and offers 99.995% uptime. This downtime is far less than typically expected to apply necessary security updates to a monolithic legacy database system. 3. Locality and global coverage Modern computing demands are at once ubiquitous and highly localized. Customers expect to be able to view their cash balances wherever they are, but client secrecy and data availability rules set strict guardrails on where data can be hosted and processed. The combination of geo-sharding, replication, and edge data addresses these problems. MongoDB Atlas in combination with MongoDB for Mobile brings these powerful tools to the developer. During the global pandemic, more consumers than ever have begun using their smartphones as payment terminals. To enable these rich functions, data must be held at the edge. Developing the synchronization of the data is difficult, however, and not a differentiator for financial institutions. MongoDB for Mobile, in addition with MongoDB’s geo-sharding capability on Atlas cloud, offloads this complexity from the developer. 4. Diverse workloads and workload isolation As more services and opportunities are developed, the demand to use the same data for multiple purposes is growing. Although legacy systems are well suited to support functions such as double entry accounting, when the same information has to be served up to a customer portal, the central credit engine, or an AI/ML algorithm, the limits of the relational databases become obvious. These limitations have resulted in developers following what is often called “best-of-breed” practices. Under this approach, data is replicated from the transactional core to a secondary, read-only datastore based on technology that is better suited to the particular workload. Typical examples are transactional data stores being copied nightly into data lakes to be available for AI/ML modelers. The additional hardware and licensing cost for this replication are not prohibitive, but the complexity of the replication, synchronization, and the complicated semantics introduced by batch dumps slows down development and increases both development and maintenance costs. Often, three or more different technologies are necessary to facilitate the usage patterns. With its developer data platform, MongoDB has integrated this replication, eliminating all the complexity for the developers. When a document is updated in the transactional datastore, MongoDB will automatically make it available for full-text search and time series analytics. The pace of change in the payments industry shows no signs of slowing. To stay competitive, it’s vital that you reassess your technology architecture. MongoDB Atlas is emerging as the technology of choice for many financial services firms that want to free their data, empower developers, and embrace disruption. Replacing legacy relational databases with a modern document database is a key step toward enhancing agility, controlling costs, better addressing consumer expectations, and achieving compliance with new regulations. Learn more by downloading our white paper “Modernize Your Payment Systems."

August 8, 2022