Month: January 2024

Article originally posted on InfoQ. Visit InfoQ

Transcript

Liang: Our topic is, improve feature freshness in large scale ML data processing. I’m Zhongliang from Meta. First of all, let’s talk about the scope of this presentation. We will be talking about feature freshness, or latency, but it has many aspects. The first one is training. When you train a model, there are different steps that can introduce latency. One is, how fresh is your training data? The other one is, how frequently do you train your model? How long does it take to train the model? Then, when the model is trained, how fast can you publish and roll out your models? These are the things about training. Another dimension is inference, or we call prediction. When your model is trained and is online, how fresh is your inference there? How fast can you fetch the data and do the inference? Out of all those different things, today we will just focus on the freshness of the inference data. We will not talk about other parts.

Why Do We Want Fresher Features?

Before diving into how to make features fresh, let’s ask the why question. Why do we want fresher features? First of all, here we are interested in a very specific type of ML task, which is called recommendation. Not just any ML task. In many other ML tasks, freshness of the data is not a requirement, it does not affect the performance of the model. Features used in recommendation are usually time invariant functions, since they represent the state of an object at a certain time point. In those cases, model performance is a function of feature, and a feature is a function of time. Here you can see a formula that gives you a rough intuition of this concept. Usually, our goal is to minimize the expectation of the loss between the prediction result and the label. As you can see, both elements in the prediction results are time relevant. The model is trained on data at a certain time point. The features are collected at a certain time point too. More practically speaking, in many application scenarios, the states of the objects are transient, for example, the interest of the user, the timeliness of the content. Both fresher training data and fresher inference data allow the model to capture trend in more recent events, so their prediction results are more relevant. These are valid through many online A/B testing. In the ideal world, we use current data to train the model, and we use current data to do the inference, so everything is instant. In reality, everything takes time so there is latency. If you look at the graph, you’ll notice we usually use older data to train the model, and relatively more recent data to do inference. In some cases, the inference data may be more stale than the training data was, something is wrong.

Now we know a fresher feature may be helpful, and we want to have a fresher feature. Naturally, we ask, you want fresher features, but by how much? How much would it affect the model performance? Can you quantify it? First of all, latency and performance is not a simple linear function. It’s hard to draw the exact curve, but we have some observations, can serve as intuitions. The chart here is for the idea only, it’s not scientific. X axis is latency, from left to right is higher latency to lower latency. Y axis is the model performance. The bottom line is lower and the top means higher performance. We have observed something like diminishing loss if you look at the curve. If a feature set is already very slow, the impact of adding additional delay is not very obvious. However, when we start to move from the left to the right along the curve, if we reduce the latency to a certain range, the model performance has started to increase significantly. That means there is a certain range where our model is more sensitive to the feature latency. Then there might be the question, what if we continue reducing the latency, will we see the diminishing returns or will we not see that? A lot of programs will keep increasing beyond certain points. It’s very hard to answer. When the latency is too low, the system becomes very complex. It’s very hard to set up a sophisticated experiment. We have different experiments with different setup, we see different results. There’s something that you can only find out if you have the right experiment setup.

How are Features Produced and Stored?

Next one, let’s talk about how features are produced and stored, so we can understand where to do the optimization. First of all, what are the computations used in feature creation? There are some basic operations. Transform is a function with one input and one output. Some examples are string parsing and typecasting. Next one is filter. We use filter to filter out data points based on certain conditions. Next one is join. It brings data together from different sources, when they are not in the same place, and especially in enriching data. For example, the event data usually only contains object IDs. In order to get the full data, a join with the dimension table is needed to bring the actual data to this place to replace the IDs, so you have the actual data. Next one is aggregation. We use it to aggregate the data over certain dimensions, for example, aggregate the gathered data over a time window. The common aggregation functions we use are sum, average, count, top-k. There are many of those. Beyond these, there are other complex computations that’s becoming more popular today, such as model inference, where you can actually run a model and use the output as the feature. We won’t cover too much of that here since the paradigm is slightly different. It might be a topic of another day. Now we know the common computations, let’s see how they are used to form a data processing flow. The chart here is the most basic flow for creating features. It is the very basic setup. We can see from left to right, we have the data source. Then we do some filter and transform. Then the data is given to aggregation function. Then, after aggregation, the data is pushed to online storage. When the model actually needs to do the inference, it will do the data fetch and then sometimes it will also need to do some online computation to process the data and then eventually feed that into the model to do the inference. Along this flow in any of those steps, you can actually do joins with other data sources to bring more data, more dimensions into the data flow. Join can happen anytime.

Some people may ask how this is different from ETL. It looks very much like ETL. Let’s zoom out a little bit to look at the bigger picture. This one is the overall data flow of the entire system. On the left side, you have the applications. Applications have data. They’re logged in ETL. They’re put into offline storage. Some are put into message bus. Then the data will be fed into the system. We previously mentioned, the join transform aggregation system. The data is processed there, and then they’re forwarded to feature storage, and they’re sitting there waiting for the model inference to happen. This is usually the entire data flow. On the left side, the logging and ETL part, these are common preprocessing of the data. The preprocessing result can be used by ML applications we’re talking about today, but they can also be used by other applications such as business intelligence, and other places that need data. These are shared upstream data processing. Here, we’re talking about something that we call feature engineering that’s focusing more on the complex last mile data processing. The complex part is, we have more complex compute patterns, and we have more specific data format. We have more interactions between different data sources, meaning different joins. We have more optimization on different stages of compute and storage. It’s more complex, it’s more ML specific. Each of those steps, they can introduce latency. We’ve looked at the compute. Now let’s look at how the data are stored, how the features are stored logically. Features represent the states of an object. Feature data are usually indexed by the primary key, which is naturally the key of the object. For example, the object can be a user or a video or a post or any other object. All features under the same primary key are usually stored together. Under the same object, each feature can also have a feature key.

Different Data Infra and their Latencies

Let’s talk about latencies. One dimension of how to provide the right latencies expectation to the features is to pick the right infra for the right task. First of all, let’s look at the different infras. In the industry, there are different data infras that provide different latency expectations. There’s batch processing, which is usually in order of hours or days. The next one is streaming infra, streaming processing. They do processing in the order of minutes or seconds. The last one, there’s also online service. You can actually do data processing with online service as well, it’s quite common. The latency expectation of online service is usually in order of milliseconds, or seconds.

Next one, let’s look at this one, one by one in detail. The first one, batch data processing. What are the features that are most suitable to be processed by batch data systems? These features are usually ingested into data sources daily or hourly. The data scale is usually too large or involves complex computation. They don’t usually change, or the models are not very sensitive to those changes. The last one is, they probably cannot be effectively computed in other infras with lower latencies. They are mostly efficiently computed in batch data processing systems. For example, Apache Spark is one of the most commonly used. Next one, streaming infra. What are the features that should be streaming features? These are usually streamed time series events. They are usually very transient, sensitive to latency. They don’t have a lot of joins between data sources, and they don’t need very complex aggregations. Because if they do, they will either come with very high performance penalties in streaming infras, or simply too difficult to do in today’s industry systems. The first step of getting the right latency is to pick the right infra.

Fine-Tuning the Infra for Better Freshness

Next one, we’ve covered the basic setups, let’s see how we can get into fine-tuning of data infra to further improve the freshness. Here, we are specifically talking about how to fine-tune streaming infra. Look at this one. This one is the basic setup, is the very basic form of streaming aggregation, streaming data processing. This is the case where aggregation is completely done offline. If you look at the chart, from the left side, you have the data source, you do the transform, and then you do the aggregation. All of this happens offline. You can also do joins offline too. Then you can see there’s a dotted line which is the separator between offline processing and online processing. After aggregation, the processed data are pushed into online storage. They’re sitting there waiting for model inference. When model inference happens, they fetch the data online, and then do some computation if necessary, and then do the inference. This is the baseline.

Next one. This one is a variation of the basic setup. In this case, we’re doing something called semi-online aggregation. We are splitting the offline aggregation into two steps. Part of it is offline and part of it is online. You can see the separation line is drawn on the online storage, so how this works. The transform events from the left side are first pushed into online storage, then the online storage will do an infrequent self-aggregation of the events and produce a partial aggregation. The partial aggregation and the raw transform events are stored together in the online storage. Then, when model inference happens, the online service will trigger a on-demand online aggregation where it will fetch the preaggregation results, the partial aggregation, and the most fresh transform events, pull both parts online, and then combine them together online to do a full aggregation. With this design, the full aggregation is done online and has lower compute cost, because some of the aggregation is already done partially offline. This one will both be able to do the full aggregation at a lower latency. It’ll also have the most fresh events captured in the full aggregation. This way, we’re able to provide a lower latency overall.

The next one. This approach is a little bit more forward thinking. Let’s step back a little bit. Ultimately, what are we doing with feature engineering? Why do we do so much aggregation, data processing? We are basically applying human knowledge on data to preprocess data into some format that’s easier for a model to perceive the relevance. Basically, all we’re doing here is baking human knowledge into the data. That’s what feature engineering is all about.

Ask ourselves, what if? What if some of the traditional data aggregation can be replaced by model itself? What if a model can learn the association between data points, without the need of traditional aggregation at all? That’s the basic idea, which is shifting feature engineering into the model, at least part of it. This is already the case in computer vision and NLP fields today, because in computer vision and NLP, you don’t have to do a lot of data aggregation outside the model. Most of those are already done as part of the neural network in the first few layers. It was difficult for recommendation a few years ago to do this when models were less capable, but a lot of things are changing very fast today. This idea is becoming more real recently.

Other Common Things to Consider

We covered the different data infras. We covered some fine-tuning of streaming infra. Next, let’s look at some other common things to consider. Number one, perf tuning. Pipeline performance tuning especially Spark. We found perf tuning especially useful in many cases. You will usually get some low hanging fruits if your dataset is large enough. We’ve seen pipeline runtime going from tens of hours to a few hours, in some cases. There are so many different Spark tuning techniques online. The general advice is, before adding more machines or upgrading your cloud service tiers, try perf tuning first and it might work better than you think. The next one, invest into data flow management. This one is often undervalued. Your data pipelines may frequently break. When the pipeline is broken, your model will get stale data, or no data at all. Your maintenance overhead is proportional to the scale of your workload. In this case, a good management system becomes very important. First of all, you can’t fix what you can’t see. Try to build good observability into the system. The second one, automated monitoring and alerts is quite basic but this one’s really hard to do right. The last one, try to automate the fixes. Some of the basic fixes are, for example, just do a retry, may help fix the problem. Codify the basic remediations and automate them so your engineers don’t have to wait and investigate and apply the fix. If you’re able to do all these to automate your management, you might reduce the level of latency just due to breakage and overhead introduced by human labor work.

Next one, let’s look at sharding offline storage in the pipelines. When you have a few hundred features and a few hundred data sources or even more, how to properly group them is a big problem. When storing your features in offline table for the same primary key, you can choose to use the white table to store all the columns together, or you can slice them vertically into multiple tables. Similarly, when computing features, you can choose to put more features into one pipeline, or divide them into multiple pipelines. Fewer tables or fewer pipelines are easier to manage, but the coupling means if part of the system is slow, or the data is corrupted, the entire thing will slow down. On the other hand, dividing them will create management overhead because you have more things to manage, but it will reduce the interdependencies. Breakage or failure in one part of the system will not propagate to other parts of the system.

Next one, let’s look at sharding online storage. This one is about feature grouping in online storage. When your features are computed, they will be stored in online storage for model inference. One object can have many features, and the features are indexed by the object ID as the primary key. Usually, we will have more than one model. That’s the common case. Not every model will use all the features. Some models will use more features, some models will use less features. When your model needs to fetch features, we will usually say, give me all features for model M under the object X. This is the common query. We’ll be using feature fetch. Then we will find the features under object X. Then we will take features used by model M, which is a subset of all features for X. There is a choice of how to partition other features under object X. We can either store them all together or add another secondary key to shard the features into smaller groups. Consider this example, two models, model 1 and model 2. Model 1 uses a small number of features and model 2 uses a large number of features. There are some overlap, but one is not a subset of the other. If we store our features together under one key, under object X, model 1 may fetch more features than needed all the time, as you can see in the bottom left chart. There is overhead of network I/O as a result of that. In the other case, if you look at the bottom right chart, if we shard the features into multiple groups, each with k features, then model 2 will always need to do a fanout. This one will add latency too. What is the best sharding strategy? Should we use a single big group, or should we use multiple small groups? There is no right answer, because this depends on the client side, how the models will use features. What you can do is, the system can open up the sharding strategy as an API, and the client side can configure it based on the query pattern.

This one is the last tip, let’s look at this chart again. Many times, we tend to look for things we want to see, and we tend to fix problems we understand better, or we think we understand it better. We tend to ignore things we care less. We may say, ok, we understand the transform compute very well, and maybe we can upgrade the technology, and then make this part run a lot faster, and we’ll have lower overall latency. Later on, we found that that’s actually not the bottleneck, the bottleneck is in a different place, where uploading the data to online storage actually takes longer time. There are many real-world examples. Say, for example, Spark is something that’s widely used in the industry. There’s lots of open resources, lots of discussions shared online. A lot of engineers are well aware of those technologies, so tend to look at that part more. Some of the parts in the entire flow are not using open source, those were built by one or two engineers years back. They are less maintained. Fewer people looked into that, understood that part less. People tend to ignore that. Many times, we found it’s not the big parts, the parts that catch attention that’s actually the bottleneck, it’s actually the smaller parts that’s running there, quietly, nobody looked at, that’s the slow part. That’s the part that actually needs an upgrade. The actual upgrade is probably not that difficult. It’s just that nobody looked at for a very long time. Something to remember.

Takeaways

Number one takeaway, freshness and model gain is a non-linear function. Sometimes there is a sweet spot, finding the right optimization range will give you the best result. Number two, freshness is not free. It comes with a cost in other forms. For example, power consumption, system complexity, or other things. Freshness is a spectrum. Not all features need to be at the same level of freshness. Because feature importance, compute cost, time sensitivity, these are all different. Remember to optimize for overall ROI, instead of just latency itself. Number three, look at the things end-to-end, instead of just focusing on one single component. More powerful infra, newer technology may not always be the best answer. Sometimes going back to the fundamentals will actually yield better results.

See more presentations with transcripts

Posted on mongodb google news. Visit mongodb google news

MongoDB, Inc. (NASDAQ:MDB – Get Free Report) saw some unusual options trading on Wednesday. Traders bought 36,130 call options on the stock. This represents an increase of approximately 2,077% compared to the typical volume of 1,660 call options.

Analyst Ratings Changes

A number of research firms have weighed in on MDB. TheStreet upgraded MongoDB from a “d+” rating to a “c-” rating in a report on Friday, December 1st. Wells Fargo & Company began coverage on MongoDB in a report on Thursday, November 16th. They issued an “overweight” rating and a $500.00 price target for the company. JMP Securities restated a “market outperform” rating and issued a $440.00 price target on shares of MongoDB in a report on Monday. Capital One Financial upgraded MongoDB from an “equal weight” rating to an “overweight” rating and set a $427.00 price target for the company in a report on Wednesday, November 8th. Finally, Truist Financial restated a “buy” rating and issued a $430.00 price target on shares of MongoDB in a report on Monday, November 13th. One research analyst has rated the stock with a sell rating, three have assigned a hold rating and twenty-one have issued a buy rating to the stock. Based on data from MarketBeat.com, the stock currently has an average rating of “Moderate Buy” and an average target price of $430.41.

Get Our Latest Analysis on MongoDB

Insider Buying and Selling at MongoDB

In other news, CAO Thomas Bull sold 359 shares of the business’s stock in a transaction dated Tuesday, January 2nd. The stock was sold at an average price of $404.38, for a total transaction of $145,172.42. Following the completion of the sale, the chief accounting officer now owns 16,313 shares in the company, valued at approximately $6,596,650.94. The sale was disclosed in a document filed with the Securities & Exchange Commission, which can be accessed through the SEC website. In other news, Director Dwight A. Merriman sold 4,000 shares of the business’s stock in a transaction dated Friday, November 3rd. The stock was sold at an average price of $332.23, for a total transaction of $1,328,920.00. Following the completion of the sale, the director now owns 1,191,159 shares in the company, valued at approximately $395,738,754.57. The sale was disclosed in a document filed with the Securities & Exchange Commission, which can be accessed through the SEC website. Also, CAO Thomas Bull sold 359 shares of the business’s stock in a transaction dated Tuesday, January 2nd. The stock was sold at an average price of $404.38, for a total value of $145,172.42. Following the sale, the chief accounting officer now owns 16,313 shares of the company’s stock, valued at approximately $6,596,650.94. The disclosure for this sale can be found here. Insiders sold 149,277 shares of company stock worth $57,223,711 in the last 90 days. 4.80% of the stock is owned by company insiders.

Institutional Investors Weigh In On MongoDB

Several hedge funds have recently modified their holdings of MDB. GPS Wealth Strategies Group LLC purchased a new stake in shares of MongoDB during the second quarter valued at $26,000. KB Financial Partners LLC purchased a new position in MongoDB during the 2nd quarter valued at about $27,000. Capital Advisors Ltd. LLC increased its holdings in shares of MongoDB by 131.0% in the 2nd quarter. Capital Advisors Ltd. LLC now owns 67 shares of the company’s stock valued at $28,000 after purchasing an additional 38 shares during the period. Bessemer Group Inc. purchased a new stake in shares of MongoDB in the fourth quarter worth approximately $29,000. Finally, BluePath Capital Management LLC acquired a new stake in shares of MongoDB during the third quarter worth approximately $30,000. 88.89% of the stock is owned by hedge funds and other institutional investors.

MongoDB Trading Down 0.2 %

Shares of MDB stock opened at $410.11 on Thursday. The stock has a 50-day simple moving average of $402.09 and a 200 day simple moving average of $380.88. MongoDB has a fifty-two week low of $179.52 and a fifty-two week high of $442.84. The stock has a market capitalization of $29.60 billion, a P/E ratio of -155.34 and a beta of 1.23. The company has a quick ratio of 4.74, a current ratio of 4.74 and a debt-to-equity ratio of 1.18.

MongoDB (NASDAQ:MDB – Get Free Report) last announced its earnings results on Tuesday, December 5th. The company reported $0.96 earnings per share for the quarter, beating the consensus estimate of $0.51 by $0.45. MongoDB had a negative return on equity of 20.64% and a negative net margin of 11.70%. The business had revenue of $432.94 million during the quarter, compared to analysts’ expectations of $406.33 million. During the same quarter last year, the business posted ($1.23) earnings per share. The company’s quarterly revenue was up 29.8% on a year-over-year basis. On average, sell-side analysts expect that MongoDB will post -1.64 earnings per share for the current fiscal year.

MongoDB Company Profile

(Get Free Report)

MongoDB, Inc provides general purpose database platform worldwide. The company offers MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premise, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

Read More

Receive News & Ratings for MongoDB Daily – Enter your email address below to receive a concise daily summary of the latest news and analysts’ ratings for MongoDB and related companies with MarketBeat.com’s FREE daily email newsletter.

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Report Ocean has recently released its “Non-Native Database Management System Market” Research Report for the years 2024-2032, presenting a comprehensive analysis of the market. This report extensively explores market dynamics, encompassing key trends, upcoming technologies, drivers, challenges, and regulatory policies. Additionally, it includes profiles and strategies of notable players in the industry. Featuring over 100+ market data tables, along with pie charts, graphs, and figures, this global market study provides a thorough comprehension of the market landscape. It offers a complete assessment covering future trends, current growth factors, well-informed opinions, factual insights, and industry-validated market data, facilitating accurate forecasts until 2032.

Non-Native Database Management System Market, valued at approximately USD $$ billion in 2024, is set to experience robust growth, projecting a substantial CAGR of over $$% over the forecast period from 2024 to 2032.  Unveiling Industry Insights, Predicting Trends, Analyzing Growth Factors, and Projecting Developments from 2024 to 2032.

Request To Download Free Sample of This Strategic Report @ https://reportocean.com/industry-verticals/sample-request?report_id=bis366357

Numerous risks could further derail what is now a precarious recovery. Among them is, in particular, the possibility of stubbornly high global inflation accompanied by tepid growth, reminiscent of the stagflation of the 1970s. This could eventually result in a sharp tightening of monetary policy in advanced economies to rein in inflation, lead to surging borrowing costs, and possibly culminate in financial stress in some emerging market and developing economies. A forceful and wide-ranging policy response is required by policy makers in these economies and the global community to boost growth, bolster macroeconomic frameworks, reduce financial vulnerabilities, provide support to vulnerable population groups, and attenuate the long-term impacts of the global shocks of recent years.

What Is Non-Native Database Management System Market:

Introduction to Non-Native Database Management System Market:

The Non-Native Database Management System (DBMS) Market is a specialized segment within the broader database management industry, focusing on solutions that provide support for databases not inherently associated with a specific programming language or framework. Unlike native databases tied to a particular platform, non-native DBMS solutions offer flexibility and interoperability across diverse database environments. This market plays a crucial role in catering to the complex data management needs of modern applications and systems that leverage multiple database technologies.

Key Features and Cross-Database Compatibility:

In-depth analysis of the Non-Native Database Management System Market reveals a comprehensive set of key features. These solutions typically offer tools for managing and querying data across various database types, allowing users to work with relational, NoSQL, or other specialized databases within a unified framework. Non-native DBMS solutions excel in providing cross-database compatibility, enabling organizations to leverage the strengths of different database technologies without being confined to a single database model. Advanced features may include support for data migration, query optimization, and centralized management of distributed databases.

Download Free Sample of This Strategic Report @ https://reportocean.com/industry-verticals/sample-request?report_id=bis366357

Industry Applications and Multi-Database Environments:

The adoption of Non-Native Database Management Systems extends across various industries, including finance, healthcare, and e-commerce. This market caters to organizations with complex data architectures that involve the use of multiple databases to meet specific application requirements. Non-native DBMS is particularly valuable for enterprises managing diverse data sources, such as customer relationship management (CRM) databases, document-oriented databases, and graph databases, within a single, integrated system.

Market Dynamics and Hybrid Data Management:

The Non-Native Database Management System Market is influenced by dynamic factors such as the rise of hybrid cloud environments, the proliferation of diverse data formats, and the need for scalable and adaptable data management solutions. Ongoing developments include the integration of non-native DBMS with cloud-based services, support for polyglot persistence, and the incorporation of advanced analytics and machine learning capabilities. The market’s adaptability to these dynamics is crucial for providing organizations with the tools to efficiently manage and derive insights from diverse and distributed data sources.

Challenges and Data Consistency:

While the market presents significant advantages, challenges such as ensuring data consistency across different databases, maintaining performance across diverse storage models, and addressing security concerns in hybrid environments may arise. Non-native DBMS providers must navigate these challenges by implementing robust transaction management, optimizing query performance, and adhering to industry standards for data security and privacy.

Download Free Sample of This Strategic Report @ https://reportocean.com/industry-verticals/sample-request?report_id=bis366357

Future Outlook and Integration with Emerging Technologies:

Looking ahead, the Non-Native Database Management System Market is poised for continuous evolution, driven by emerging trends and the integration with cutting-edge technologies. Future-oriented developments may include increased integration with edge computing, support for blockchain-based databases, and enhanced tools for managing unstructured data. As organizations increasingly adopt a diverse array of databases to meet specific business needs, non-native DBMS will play a pivotal role in shaping the future of flexible, scalable, and interoperable data management solutions.

This Report covers the manufacturer data, including: sales volume, price, revenue, gross margin, business distribution etc., these data help the consumer know about the competitors better. This report also covers all the regions and countries of the world, which shows the regional development status, including market size, volume and value, as well as price data. Besides, the report also covers segment data, including: type segment, application segment, channel segment etc. historic data period is from 2024-2032, the forecast data from 2024-2033.

Market Segments :

Key Players:

Amazon Web Services
Microsoft
Oracle
Quest Software
PremiumSoft CyberTech
Webyog
3T Software Labs
MongoDB
Devart
TablePlus
DbVis Software
Lean Software
Caspio
Actian
Cardett Associates

Download Free Sample of This Strategic Report @ https://reportocean.com/industry-verticals/sample-request?report_id=bis366357

Product Type Segment
On-premise
Cloud-based

Application Segment
Individual
Enterprise

Channel Segment

Direct Sales,

Distribution Channel

Region Segment:

North America (United States, Canada, Mexico)
South America (Brazil, Argentina, Other)
Asia Pacific (China, Japan, India, Korea, Southeast Asia)
Europe (Germany, UK, France, Spain, Russia, Italy)
Middle East and Africa (Middle East, South Africa, Egypt)

Table of Content

1. Introduction
   1. Study Assumptions
   2. Scope of the Study
2. Research Methodology
3. Executive Summary
4. Market Dynamics
   1. Market Drivers
   2. Market Restraints
   3. Industry Attractiveness – Porter’s Five Forces Analysis
5. Market Segmentation
6. Competitive Landscape
   1. Vendor Market Share
   2. Company Profiles
7. Market Opportunities and Future Trends
8. Industrial Chain, Downstream Buyers, and Sourcing Strategy
9. Marketing Strategy Analysis

………Continued…!

Market Research Industry Report Overview:

Introduction:

In the dynamic and ever-evolving realm of the market research industry, a comprehensive understanding of driving forces, constraints, growth opportunities, and challenges is imperative for stakeholders striving to maintain a competitive edge. This report provides an in-depth exploration of the diverse facets shaping the trajectory of the industry.

Driving Forces:

Unveiling the Propelling Forces of Market Research The market research industry experiences propulsion from an array of driving factors that not only contribute to its current growth and relevance but also lay the groundwork for its future.

• Technological Advancements: The integration of cutting-edge technologies like artificial intelligence and machine learning is revolutionizing market research processes, enhancing efficiency, and delivering more precise insights.
• Globalization: With businesses expanding globally, the demand for comprehensive market insights on an international scale has become imperative, driving the need for global market research services.
• Consumer-Centric Approach: Evolving consumer behaviors prompt businesses to adopt a more customer-centric approach, intensifying the demand for nuanced market research tailored to specific demographics.

Download Free Sample of This Strategic Report with Industry Analysis @ https://reportocean.com/industry-verticals/sample-request?report_id=bis366357

Restraining Factors:

Navigating Challenges in the Market Research Landscape Despite experiencing growth, the market research industry is not immune to challenges that may impede its progress. Identifying and addressing these restraining factors is crucial for sustaining a resilient and adaptive industry.

• Data Privacy Concerns: Heightened awareness and regulations surrounding data privacy pose challenges for market researchers, necessitating the adoption of ethical practices and robust data protection measures.
• Budget Constraints: Economic uncertainties and budget constraints may limit the resources allocated to market research endeavors, impacting the scope and quality of obtainable insights.
• Saturation in Traditional Methods: With traditional research methods reaching saturation, the industry faces the challenge of embracing innovation and adapting to emerging methodologies to maintain relevance.

Growth Opportunities:

Exploring Avenues for Expansion and Innovation Within the challenges, the market research industry is presented with growth opportunities that can be harnessed to stay competitive and foster innovation.

• Emerging Markets: The untapped potential of emerging markets provides an opportunity for market researchers to explore and establish a presence in regions with evolving consumer landscapes.
• Customized Solutions: Offering personalized and industry-specific research solutions can cater to the growing demand for tailored insights, creating new avenues for revenue and market expansion.
• Integration of Big Data Analytics: Leveraging big data analytics for in-depth analysis and predictive modeling opens doors to uncover hidden patterns and trends, enhancing the value proposition of market research services.

Challenges:

Addressing Hurdles on the Horizon In the dynamic market research landscape, persistent challenges require proactive strategies and innovative solutions to overcome.

• Technology Adoption: While technological advancements present opportunities, the rapid pace of adoption can pose a challenge, requiring industry players to stay agile and continually update their skillsets.
• Interpreting Unstructured Data: The influx of unstructured data from diverse sources necessitates advanced analytics tools and methodologies to extract meaningful insights, posing a challenge for traditional research frameworks.
• Competitive Landscape: Intensifying competition within the market research industry necessitates differentiation strategies, compelling organizations to showcase unique value propositions to stand out in a crowded market.

Some of the Key Aspects that the Report Analyses:

• Which regions in Market are witnessing rise in investments in the supply chain networks?
• Which regions have witnessed decline in consumer demand due to economic and political upheavals in Molecular Beam Epitaxy System Industry?
• Which countries in Market seem to have benefitted from recent import and export policies?
• Which are some the key geographies that are likely to emerge as lucrative markets?
• What are some the sustainability trends impacting the logistics and supply chain dynamics in the Market?
• What are some of the demographic and economic environments that create new demand in developing economies?
• Which regions in Market are expected to lose shares due to pricing pressures?
• Which regions leading players are expected to expand their footprints in the near future in Molecular Beam Epitaxy System Industry?
• How are changing government regulations shaping business strategies and practices?

Request full Report: @ https://reportocean.com/industry-verticals/sample-request?report_id=bis366357

About Report Ocean:

Report Ocean stands as a preeminent provider of market research reports within the industry. Renowned globally, we are acclaimed for delivering insightful and informative research reports. Our commitment lies in furnishing clients with a comprehensive blend of both quantitative and qualitative research outcomes. As an integral component of our expansive global network and thorough industry coverage, we offer an in-depth reservoir of knowledge that empowers strategic and well-informed business decisions. Our approach integrates cutting-edge technology, advanced analysis tools, and our proprietary research models, all underpinned by years of expertise. This synergy allows us to craft essential details and facts that consistently surpass expectations.

Connect with Us:

Report Ocean:
Address: 500 N Michigan Ave, Suite 600, Chicago, Illinois 60611 – UNITED STATES
Visit Our News Website: https://reportocean.com
Tel: +1888 212 3539 (US – TOLL FREE)
Email: [email protected]

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

MongoDB (MDB) closed the most recent trading day at $410.11, moving -0.23% from the previous trading session. This move lagged the S&P 500’s daily gain of 0.08%. Meanwhile, the Dow experienced a drop of 0.26%, and the technology-dominated Nasdaq saw an increase of 0.36%.

Heading into today, shares of the database platform had lost 1.4% over the past month, lagging the Computer and Technology sector’s gain of 4.29% and the S&P 500’s gain of 2.4% in that time.

Investors will be eagerly watching for the performance of MongoDB in its upcoming earnings disclosure. The company’s upcoming EPS is projected at $0.46, signifying a 19.3% drop compared to the same quarter of the previous year. Alongside, our most recent consensus estimate is anticipating revenue of $431.99 million, indicating a 19.56% upward movement from the same quarter last year.

Looking at the full year, the Zacks Consensus Estimates suggest analysts are expecting earnings of $2.90 per share and revenue of $1.66 billion. These totals would mark changes of +258.02% and +29.04%, respectively, from last year.

Investors should also take note of any recent adjustments to analyst estimates for MongoDB. These recent revisions tend to reflect the evolving nature of short-term business trends. As a result, upbeat changes in estimates indicate analysts’ favorable outlook on the company’s business health and profitability.

Our research shows that these estimate changes are directly correlated with near-term stock prices. To exploit this, we’ve formed the Zacks Rank, a quantitative model that includes these estimate changes and presents a viable rating system.

The Zacks Rank system, which ranges from #1 (Strong Buy) to #5 (Strong Sell), has an impressive outside-audited track record of outperformance, with #1 stocks generating an average annual return of +25% since 1988. The Zacks Consensus EPS estimate remained stagnant within the past month. MongoDB presently features a Zacks Rank of #2 (Buy).

With respect to valuation, MongoDB is currently being traded at a Forward P/E ratio of 141.69. This signifies a premium in comparison to the average Forward P/E of 35.77 for its industry.

The Internet – Software industry is part of the Computer and Technology sector. This industry currently has a Zacks Industry Rank of 57, which puts it in the top 23% of all 250+ industries.

The strength of our individual industry groups is measured by the Zacks Industry Rank, which is calculated based on the average Zacks Rank of the individual stocks within these groups. Our research shows that the top 50% rated industries outperform the bottom half by a factor of 2 to 1.

Don’t forget to use Zacks.com to keep track of all these stock-moving metrics, and others, in the upcoming trading sessions.

Want the latest recommendations from Zacks Investment Research? Today, you can download 7 Best Stocks for the Next 30 Days. Click to get this free report

MongoDB, Inc. (MDB) : Free Stock Analysis Report

To read this article on Zacks.com click here.

Zacks Investment Research

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

California Public Employees Retirement System boosted its holdings in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 26.1% in the third quarter, according to its most recent filing with the Securities and Exchange Commission (SEC). The institutional investor owned 120,737 shares of the company’s stock after purchasing an additional 25,005 shares during the period. California Public Employees Retirement System owned 0.17% of MongoDB worth $41,758,000 as of its most recent SEC filing.

Several other institutional investors have also recently bought and sold shares of MDB. Simplicity Solutions LLC lifted its position in shares of MongoDB by 2.2% during the second quarter. Simplicity Solutions LLC now owns 1,169 shares of the company’s stock worth $480,000 after purchasing an additional 25 shares in the last quarter. AJ Wealth Strategies LLC lifted its holdings in MongoDB by 1.2% during the 2nd quarter. AJ Wealth Strategies LLC now owns 2,390 shares of the company’s stock worth $982,000 after buying an additional 28 shares in the last quarter. Assenagon Asset Management S.A. lifted its holdings in MongoDB by 1.4% during the 2nd quarter. Assenagon Asset Management S.A. now owns 2,239 shares of the company’s stock worth $920,000 after buying an additional 32 shares in the last quarter. Veritable L.P. boosted its position in MongoDB by 1.4% in the 2nd quarter. Veritable L.P. now owns 2,321 shares of the company’s stock valued at $954,000 after buying an additional 33 shares during the last quarter. Finally, Choreo LLC raised its position in shares of MongoDB by 3.5% during the second quarter. Choreo LLC now owns 1,040 shares of the company’s stock worth $427,000 after acquiring an additional 35 shares during the last quarter. Institutional investors own 88.89% of the company’s stock.

Wall Street Analyst Weigh In

Several research firms recently issued reports on MDB. Scotiabank assumed coverage on MongoDB in a report on Tuesday, October 10th. They issued a “sector perform” rating and a $335.00 price target on the stock. Capital One Financial raised shares of MongoDB from an “equal weight” rating to an “overweight” rating and set a $427.00 target price on the stock in a research note on Wednesday, November 8th. TheStreet raised shares of MongoDB from a “d+” rating to a “c-” rating in a research note on Friday, December 1st. Stifel Nicolaus reaffirmed a “buy” rating and issued a $450.00 price objective on shares of MongoDB in a research note on Monday, December 4th. Finally, Truist Financial reaffirmed a “buy” rating and set a $430.00 target price on shares of MongoDB in a report on Monday, November 13th. One investment analyst has rated the stock with a sell rating, three have assigned a hold rating and twenty-one have issued a buy rating to the stock. According to MarketBeat, MongoDB currently has a consensus rating of “Moderate Buy” and a consensus target price of $430.41.

Get Our Latest Stock Analysis on MDB

Insiders Place Their Bets

In other news, CRO Cedric Pech sold 1,248 shares of the firm’s stock in a transaction dated Tuesday, January 16th. The stock was sold at an average price of $400.00, for a total value of $499,200.00. Following the completion of the transaction, the executive now owns 25,425 shares in the company, valued at approximately $10,170,000. The sale was disclosed in a filing with the Securities & Exchange Commission, which is available through this hyperlink. In other news, CRO Cedric Pech sold 1,248 shares of the company’s stock in a transaction that occurred on Tuesday, January 16th. The stock was sold at an average price of $400.00, for a total transaction of $499,200.00. Following the sale, the executive now owns 25,425 shares in the company, valued at approximately $10,170,000. The sale was disclosed in a document filed with the SEC, which is available at the SEC website. Also, Director Dwight A. Merriman sold 4,000 shares of the firm’s stock in a transaction on Friday, November 3rd. The shares were sold at an average price of $332.23, for a total transaction of $1,328,920.00. Following the completion of the transaction, the director now directly owns 1,191,159 shares of the company’s stock, valued at $395,738,754.57. The disclosure for this sale can be found here. Insiders have sold 148,277 shares of company stock valued at $56,803,711 in the last three months. 4.80% of the stock is currently owned by corporate insiders.

MongoDB Stock Down 0.6 %

NASDAQ:MDB opened at $411.06 on Wednesday. The company has a market cap of $29.67 billion, a PE ratio of -155.70 and a beta of 1.23. The stock has a 50-day simple moving average of $401.74 and a 200 day simple moving average of $380.67. The company has a debt-to-equity ratio of 1.18, a quick ratio of 4.74 and a current ratio of 4.74. MongoDB, Inc. has a 52-week low of $179.52 and a 52-week high of $442.84.

MongoDB (NASDAQ:MDB – Get Free Report) last posted its quarterly earnings data on Tuesday, December 5th. The company reported $0.96 earnings per share (EPS) for the quarter, beating analysts’ consensus estimates of $0.51 by $0.45. The company had revenue of $432.94 million for the quarter, compared to the consensus estimate of $406.33 million. MongoDB had a negative net margin of 11.70% and a negative return on equity of 20.64%. The firm’s revenue was up 29.8% compared to the same quarter last year. During the same period last year, the company earned ($1.23) earnings per share. On average, sell-side analysts expect that MongoDB, Inc. will post -1.64 EPS for the current fiscal year.

MongoDB Profile

(Free Report)

MongoDB, Inc provides general purpose database platform worldwide. The company offers MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premise, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

Further Reading

This instant news alert was generated by narrative science technology and financial data from MarketBeat in order to provide readers with the fastest and most accurate reporting. This story was reviewed by MarketBeat’s editorial team prior to publication. Please send any questions or comments about this story to contact@marketbeat.com.

Before you consider MongoDB, you’ll want to hear this.

MarketBeat keeps track of Wall Street’s top-rated and best performing research analysts and the stocks they recommend to their clients on a daily basis. MarketBeat has identified the five stocks that top analysts are quietly whispering to their clients to buy now before the broader market catches on… and MongoDB wasn’t on the list.

While MongoDB currently has a “Moderate Buy” rating among analysts, top-rated analysts believe these five stocks are better buys.

View The Five Stocks Here

MarketBeat’s analysts have just released their top five short plays for February 2024. Learn which stocks have the most short interest and how to trade them. Click the link below to see which companies made the list.

Get This Free Report

Article originally posted on mongodb google news. Visit mongodb google news

Article originally posted on InfoQ. Visit InfoQ

Subscribe on:

Apple Podcasts
Google Podcasts
Soundcloud
Spotify
Overcast
Podcast Feed

.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Article originally posted on InfoQ. Visit InfoQ

Transcript

Pisani: Welcome to my talk, living on the edge, boosting your site’s performance with edge computing. My name is Erica. I am a senior software engineer at Netlify, working on the integrations team.

We’re going to talk about, what is the edge. We’re going to look at hosting web application functionality on the edge, looking specifically at Edge Functions. We’re going to look at accessing and caching data on the edge to help boost site performance through that mechanism. A little bit of a surprise toward the end there, what I’m calling the edgiest part of the edge. Then a wrap-up.

What Is the Edge?

What is the edge? To understand that, we need to understand a little bit about how cloud providers like AWS, Google Cloud Platform, and Microsoft Azure, organize their servers. We’re just going to touch on that very briefly. At the broadest possible scope, things are organized by regions. Think your Canada Central, your U.S.-East-1, your EU Central, and availability zones. There’s a number of these within regions, and they contain one or more data centers. When we talk about an origin server, we’re commonly referring to a server that is hosted in one of these availability zones. The edge are just data centers that live outside of an availability zone. An Edge Function is a function that’s run on one of these data centers that lives outside of an availability zone. Data on the edge being data that’s cached, stored, I include even accessing on one of these data centers. You might also see the term points of presence, or POPs, or edge location to refer to these, like edge locations, it just depends on the cloud provider that you’re working with. To give a sense of just how many more edge locations that are there in the world relative to availability zones, I grabbed this from AWS’s documentation. This is a map of all their availability zones in their global network. Then if I pop to this next slide, these are all the edge locations. Those orangey-yellowish larger circles on this map are regional edge caches, they’re slightly larger caches than what you would find at an edge location, but maybe not as big as what you would find on an origin server.

You can see immediately at a glance that if you’re able to handle a user’s requests through the edge network, you can improve site performance significantly by lowering the latency incurred from receiving and fulfilling the request. In particular, I’m looking at maybe users that are based in South America, Africa, or Australia regions, where there’s only one availability zone, but they have multiple edge locations. If for some reason, you have to host the user’s data in that availability zone, having some of the requests, at least the most popular ones handled at the edge means that users that are located at the other end of those regions will benefit from faster responses due to the proximity of the server being much closer to them. Let’s take a quick look at where the edge fits in in a request lifecycle. In this diagram, I have a user that’s based in South America and they’re making a request. What will happen is that little red diamond thing, that’s our edge location. It’ll be the first to pick up the request. The best possible case scenario is that the edge location is able to fulfill the request in its entirety, and it sends a response back to the user. Let’s say that it can’t for whatever reason, let’s say your site was just deployed and so the cache has been invalidated. Or maybe this is a request that’s not made very often, and so you just don’t cache it, or the cache has expired if you do cache it. What’ll happen is the edge location will make a request to the origin server. The origin server will handle it normally, and then send a response back to the edge location. At this point, you have the option to cache the origin response, and then the edge location will send the response back to the user. If it’s something that’s requested often, I highly encourage caching at this location, because what that means is that other users that are in proximity to that edge location that would make a request will benefit from that cache response. You remove that need from the edge location to have to make a request to the origin server.

Web Application Functionality on the Edge Using Edge Functions

Let’s talk about web application functionality on the edge using Edge Functions, now that we’ve done an overview of what the edge is and where it fits in the lifecycle of a request. For me, it’s best to demonstrate how useful the edge can be by giving some kinds of problems to work through. One of these is handling high traffic or a high traffic page that serves localized content. Imagine for a moment that I have a thriving global e-commerce business, maybe a pet store. I’m looking for opportunities for some easy wins to remove load from the server and return cache responses. The challenge is that because I’m serving localized content, let’s say it’s the homepage and I have a banner that maybe promotes sales in certain cities, welcome messages, and others, things like that, that I’ve been relying on the server to inject that dynamic content before sending it back to the user. How can I use Edge Functions to help address this, or the edge in general? The way that I can do that is by transforming the server-side rendered page into a static one and injecting that localized content using an Edge Function. This transition, what that would mean is that by transitioning to a static page, you’re able to cache that page on the content delivery network, or CDN, for faster access of that page going forward. You’re removing the load on the origin server that existed previously, because rather than having to render the page every time it received a request, that would just be handled by an Edge Function. Then you have the option to cache that generated page on the Edge Function.

Let’s take a look at some code. My hypothetical e-commerce website is an xjsf. Both the middleware function on the left-hand side and the page that is server-side rendered based on the presence of getServerSideProps, both of these are running on the origin server. To go through the code here, starting with the middleware, what’s happening is I’m getting the geo object off of the request object. I’m getting the country off the geo object, and then I’m adding that value onto the URL before rewriting the request. Going to the right-hand side, I’m getting that query parameter off of the URL. Then based on the value of it, if the user is based in Canada, and I want to have a bit of a hometown sale going on for my store, I’m giving a promo code of 50% off their order for my Canadian customers, but a very friendly Hello world for the rest of the world. The server will render that HTML based on the value and then send that response back to the user. To recap, the server has to render this every time. It’s not cacheable on the CDN. You could create different pages to route to in order to make the pages cacheable, but that will result in duplicated logic and it can get out of hand really quickly for anything even slightly bigger than a small hobby site. We want to avoid that as much as possible.

That brings us to our static and Edge Functions example. You’ll notice that the middleware function’s a little bit bigger now. The page that we have on the right-hand side is now a static one based on the presence of getStaticProps. What’s not obvious from the code here is that in this code example, the middleware is running on the edge. Just keep that in mind as we’re going through this. The first two lines of the middleware function are the same as before, getting the geo objects off the request, and getting the country off the geo object. The next line, const request = new MiddlewareRequest. I’m leveraging some functionality in the Netlify Next package that does some cool stuff in the next few lines. The one after that const response = await request.next, what’s happening here is the request is going to the origin. Rather than the origin server, what’s happening is it’s getting the page that’s cached on the CDN so that’ll be a faster request to fulfill. At that time, the value of response is the rendered HTML with the banner that says Hello world. As we talked about before, the use case here is that I need to show different banner messages depending on where the user is located. How I’m doing that is by determining if the user is based in Canada, and this is where the fancy middleware functionality is coming in. I am updating the text of the HTML response.replaceText with the message that I want to show, and then updating the Next.js page prop before returning that response back to the client. Where before, like a little further up, response = await request.next, the banner said Hello world, with the following block there, that if conditional. I will have updated it so that it shows the correct thing that I want so the client will see the Hello Canada promo code banner. You can cache this on the edge, which means that more than likely requests that are coming in from users, they’re going to be picked up by that edge location, they’re likely also going to want that same response. You’re saving that extra trip to the CDN, in this case. The request starts getting handled sooner, the user gets the response much sooner, so there’s small performance gains by doing this, compared to our original thing where we had to go to a potentially distant origin server, run that, and then return the response.

Another great use case for Edge Functions and boosting site performance is user session validation. Let’s say that on this pet store site that I have, there’s some high traffic pages that require a user to have an account. I notice that the user session validation is taking a little bit more time than I’d like, especially for some users that are physically further away from the origin server. I also know that it’s often the case that all the users that interact with these specific pages are not initially signed in. They’re making a request and it’s reaching the origin server and then coming back with like, “You’re not authorized to look at this page. You need to sign in,” and redirected to the login page. How can we get some performance gains here? The way that we can do that is by doing the session validation on an Edge Function. Using Auth0, because that’s one of the more popular providers out there for this functionality. What I’m doing here is, with like two lines of code, I have made it so that you need to have an account to log in to the website. Right now, this is just guarding the whole website that I have. What you could do is you can modify this to look at either through like something as part of a cookie, or if you’re using a JSON web token in an OAuth application, you can look at roles. If someone’s an admin, they get access to this page, or someone’s a paying subscribing member, they get access to this content on your website.

The last one I want to talk about is routing a third-party integration request to the correct region. This particular problem is very near and dear to my heart, because I ran into this a few years ago. I was working at a company where we had two origin servers, one in North America and one in the EU. Users and their data would live in one of these, but not both. Because we were looking to comply with certain privacy laws and customer requests that involve hosting data in a particular region, we had to get a little bit funky at times with trying to figure out where the user was located, in a performant way. We also had third-party integrations that we need to support that would want to access or modify our user’s data. That took out the option for us to maybe use geo locating because the request that was coming in on behalf of the user might be coming from a place where the user isn’t located. The user might be in Europe, but the integrator or the integration has their servers based in Australia, or South America, or North America.

Let’s go through the authorization flow for an integration just to really paint a picture about how this was such a problem for us. An integration is being enabled by a user on a third-party integration site, so let’s say in Australia. The request would go from Australia to my company’s original origin server first, which is based in North America. We would check to see if the user existed within that region. If not, we need to check and confirm that the user didn’t exist in the other region. Then if they did, return a response back to the integration as part of the authorization data flow. One consideration that we had to optimize the subsequent API requests after that initial authorization was to return a URL that integrations would then make future requests against, either to North America or the EU as part of the authorization response. You can already get a sense that it’s leaking an implementation detail, which is not ideal, it’s easy to get wrong. It’s more data that the integration has to store. If something changed in the future, we’re now stuck with having to support all these integrations that now have these URLs as part of their data, and their implementation of their integration against our site. We also looked at encoding the region on the JSON web token as part of an OAuth authorization flow. It was ultimately the preferred approach. What this meant is that we had to run a proxy server in both regions to route the request to the correct region if a decoded JSON Web Token indicated that the user’s data belonged in the other one. You’re still having to make a transatlantic request as part of this, potentially. That’s a lot of traveling for a request. That’s a lot of latency introduced just by where the request is being redirected to. As mentioned before, the URL approach meant that the integration needed to know an implementation detail in order to have the most optimal requests sent to our servers. The encoded region approach still meant that even though it took out the need for the integration to know which URL to go to, it meant that it could still be bounced around the world and we now have the service that was potentially a bottleneck for performance or a failure point in the request. It could be hard to debug what was the issue if the request started failing.

Now that I’ve been looking at Edge Functions, I’m realizing that the edge would have been really handy here, just using a simple Edge Function would have made our lives a lot easier. We couldn’t get around needing to encode the region on the JSON web token, but it’s a small piece of data to add. Then, what we could do is relocate that proxy code to that Edge Function, and then that Edge Function would do the routing for us. What that would look like is, going back to our integration based in Australia, they would make a request and the edge location would pick it up. We could decode the token. Then based on the region that’s there, we go directly to the EU instance, or directly to the North America instance. Much faster, very straightforward. You don’t need to spin up a distinct service for this. Architecturally, it’s quite simple. It results in a reliable, better performance. If the request is one of those where the response is something you’d want to cache, now it’s cached physically closer to the integration, and it’ll be much faster to access going forward rather than caching at the origin server and you still have to make that very long-distance request.

Data on the Edge

Let’s talk about data on the edge. For those who’ve been developing in the JavaScript ecosystem for a while, you’re probably familiar with the debates that have been made over the years about how to boost website performance through how a website is architected. I’m talking specifically about whether to build a single page application leaning more into an island’s architecture, favoring the server with server-side rendering, things like that. Regardless of which camp you tend to gravitate towards with how you want to build your site, having the ability to load data on a server physically closer to the user can be an enormous help here in terms of boosting your site’s performance. Before we get into a couple providers that do this, it’s worth noting that historically there has been challenges of hosting and accessing data on the edge. They’re the same challenges that I think just databases in general have, managing the limited number of connections that databases have available to them when you’re experiencing a high amount of traffic, and ensuring that data remains consistent, especially if you’re caching it in various places. In a serverless and Edge Function environment, how do you make sure that you don’t run out of connections on your database when you’re suddenly spinning up hundreds of thousands of serverless functions or Edge Functions to handle a spike in traffic? If you’re caching stuff on the edge, how do you ensure that that data remains consistent or promptly invalidated if that data is modified somewhere else in the world?

We’re going to talk first about the limited number of connections. Much like with the traditional monolithic database, this is tackled using connection pooling. What that is, is it’s a collection of open connections that can be passed from operation to operation as needed. It gives you a bit of a performance bump with handling database queries because it’s removing the overhead of needing to open and close the connection on every operation. A tool that uses this for a serverless and Edge Function environment is Prisma Data Proxy. What they do is they create an external connection pool, and requests for the database need to go through this proxy before it reaches the database itself. Another database provider that leverages this connection pooling approach is PlanetScale. They use Vitess, which is an open source database clustering system for MySQL under the hood, and leverage its connection pooling at the VTTablet level. By doing this, they can scale the connection pooling with the database cluster. If you’re interested in learning more about how they’ve managed this, they have a blog post detailing that they were able to handle a million requests a second, which is just mind boggling to me, and they had no issues.

Going over to the data consistency side of things, Cloudflare’s Durable Objects is one approach that was taken. Cloudflare, or the CDOs, what they’ve done here is they’ve basically taken the monolithic database and broken it down into small logical units of data. When you’re creating a durable object, Cloudflare automatically determines for you where that object will live. It’s usually on an edge location closest to the user making the request that initially created it. It can change regions if you need it to. In the future, let’s say you find that it’s maybe more performant to have it somewhere else, you can do that quite easily. They’re globally unique, and they can only see and modify their own data. If you needed to access or modify data across multiple durable objects, it usually would have to happen on your application level. They’re accessed through Cloudflare’s internal network using Cloudflare Workers. The use of their internal network ensures that accessing them is performant, and much faster than if you’re just accessing them over the public internet. Going back to PlanetScale, they also use an internal network approach. They say that it operates similar to a CDN. When someone is trying to modify or access data, what will happen is a client will connect to the closest geographic edge on PlanetScale’s network, and then they will backhaul the request over long held connection pools in their internal network to reach the actual destination. Initially, I was a little bit skeptical when I was reading it. Apparently, in terms of the performance gains, since it could be traveling quite far for the data, but with how they’ve set up their internal network, it’s actually able to reduce the latency of the requests compared to if you were just to do it over the public internet.

We’ll take a quick look at how fetching data on the edge looks like. Using PlanetScale, it’s pretty straightforward. This is a function that’s running on the edge on Netlify services, so that’s why it’s using the Deno runtime here. On lines 12 and 13, that’s where we’re connecting to the database and making a request to the database, and doing a query for the five most popular items where there’s still stock available in my inventory. Then continuing on with the request. At the moment, this will query the database every single time. It’s not necessarily the most efficient. Given that this queries the kind that would be on, let’s say, the homepage, or some other high traffic page because it’s showing a list of the most purchased items that we still have available, caching would likely be useful here. Other users will likely benefit from having that cached response. Let’s take a look at what that looks like. I have to add the caveat that this is very experimental code on Netlify side. It’s still a little bit of a work in progress and not widely available. I wanted to demonstrate this just to give a sense of how easy it can be to cache on the edge. Lines 12 and 13 are the same. Then in the response that I’m returning, I’m returning the results from the database query on line 13. Then adding a cache control header to indicate how long I want this to live for. This will be on this endpoint called getPopularProducts, which is what you can see on line 23 in the config object. Someone makes maybe the initial request and it’ll make the response. It’ll invoke the function, query the database, send the response back. Other users will, rather than have the Edge Function invoked, it’ll actually have the result served from the cache. You’re saving a little bit of money because you’re not invoking the Edge Function. Then, this result can be reused across multiple clients, especially because this is such a more generic, not user specific result.

The Edgiest of the Edge

I want to mention a product that is part of the edge but not in the way that we think. The main assumption, in everything that we’ve talked about so far, is that there’s always reliable internet access. What if that isn’t the case? A lot of the world still has maybe intermittent or non-existent internet. Where can the edge come in to help serve these areas? That brings me to AWS Snowball Edge. This one blew my mind when I first heard about it. I heard about it from a colleague who works at AWS, and I hadn’t heard of it before, he hadn’t heard about it until he worked at AWS. This is an edge offering from Amazon as a way of making cloud computing available in places that have unreliable or non-existent internet, or as a way of migrating data to the cloud if bandwidth is also a bit of an issue, or just connecting to the internet reliably for a long period of time is a challenge. Locations that would benefit from using this are ships, windmills, and remote factories, which is just wild to me. On the right-hand side, this is a picture of what Snowball Edge looks like. If you’ve seen a computer in the ’90s, it looks like a computer in the ’90s. You order it online, it gets mailed to you, and you can run lambda functions on it. It sounds a little bit like on-prem, but it is a way of making cloud computing available to places that just can’t reliably connect to the internet. I really want to highlight this, because given there’s a lot of places in the world that have maybe not a reliable source of internet or it doesn’t exist just straight up, we may need to consider, depending on the products that we’re building, delivering them similar to how Snowball Edge delivers their edge and cloud computing to these areas and are so on the edge that they’re literally on our users’ doorsteps.

Limitations of the Edge

We’ve talked a lot about where the edge can help your site performance in terms of web application functionality, or serving data closer to our users. It sounds all nice, but what are the limitations? Which I think is not too bad, all things considered actually for the benefits of using the edge. There’s lower CPU time on these Edge Functions. It means that you can do less operations within that function compared to an origin function. Generally, it’s not too bad, but it depends wildly on the vendor that you’re using. It just means you can do less operations. Advantages on the edge with its physical proximity close to the users can be lost when a network request is made from there to an origin server. You ideally want to try and reduce the need to make origin server requests as much as possible, because it could be very distant and has the potential to negate the benefits of performing the operation on the edge in the first place. There’s also limited integration with other cloud services. Let’s say for a second that you’re using an AWS serverless lambda, and you’re using maybe some native integration with another AWS service, and you want that same thing to exist maybe on the edge. AWS only has maybe a dozen or so of their general service offering that can integrate quite closely with the edge, but they have hundreds of opportunities between their standard AWS serverless lambda and their other services. That might be a reason for you to not move some functionality onto the edge. It’s also very expensive to run. If cost is a concern for you, or you don’t want to make your chief financial officer too angry at you, choose what you’re moving to the edge wisely. There are, in most sites, small pieces of functionality that would get a bit of a performance boost and not cost too much to move to the edge. Moving your entire site and all its functionality might be a little bit too expensive for where you’re at, maybe in your company’s life.

Summary

We’ve covered a lot on what edge capabilities are out there that can help boost our website performance. We’ve looked at a simple use case of serving localized content that went from being served by the origin server to being served on the CDN and at the edge using Edge Functions. We’ve also taken a look at speeding up our user authorization flow by moving a common operation to the edge, validating user sessions, rather than handling it at a distant origin server. We’ve also looked at the future where data is being hosted closer to our users that are distributed all over the globe, either through something like Cloudflare Durable Objects, that allow you to no longer have to worry about which region to host the data in. Or AWS Snowball, where storage and compute capabilities can literally be shipped to your doorstep and can operate in areas with non-existent or unreliable internet. While we’ve looked at some of their limitations, we can also see some of the use cases where we should feel comfortable handling requests at the edge as the preferred default rather than at a maybe very distant origin server.

Entering an Edge-First Future

What you can do in the near future at your place of work is investigate some of the high traffic functions and functionality and see if they can maybe become an Edge Function. Some other use cases that Edge Functions can be used to great effect is like setting cookies, setting custom header, something that’s really small and focused and isn’t too tangled up in the rest of the site’s architecture. You can maybe get a very quick, easy performance boost with minimal changes on your part and just changing where that code runs. Also take a look at maybe some user locations with the highest latencies that you can see in your metrics, and maybe try handling some of the more popular requests at the edge rather than origin server. You might end up seeing some higher rates of user satisfaction as a result of changing where some of these more popular requests are handled. All that is to say we’re beginning to enter an edge-first future. For me, this is so exciting, because the more requests and data that you can serve closer to your users, the better the experience of your site will be regardless of where the user is based in the world.

See more presentations with transcripts

Posted on mongodb google news. Visit mongodb google news

Daiwa Securities Group Inc. increased its holdings in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 1.7% during the third quarter, according to its most recent Form 13F filing with the Securities and Exchange Commission. The firm owned 5,724 shares of the company’s stock after acquiring an additional 93 shares during the quarter. Daiwa Securities Group Inc.’s holdings in MongoDB were worth $1,980,000 as of its most recent SEC filing.

Several other hedge funds and other institutional investors have also bought and sold shares of the business. AIA Group Ltd purchased a new position in MongoDB in the third quarter valued at approximately $1,141,000. Wealthfront Advisers LLC lifted its position in shares of MongoDB by 13.4% during the 3rd quarter. Wealthfront Advisers LLC now owns 4,004 shares of the company’s stock valued at $1,385,000 after buying an additional 472 shares during the last quarter. Mitsubishi UFJ Morgan Stanley Securities Co. Ltd. bought a new position in shares of MongoDB during the 3rd quarter worth $702,000. Teacher Retirement System of Texas increased its holdings in MongoDB by 3.3% in the 3rd quarter. Teacher Retirement System of Texas now owns 5,469 shares of the company’s stock worth $1,892,000 after acquiring an additional 173 shares during the last quarter. Finally, CTC Alternative Strategies Ltd. bought a new stake in MongoDB in the 3rd quarter valued at about $415,000. Hedge funds and other institutional investors own 88.89% of the company’s stock.

Insider Activity

In related news, CEO Dev Ittycheria sold 100,500 shares of MongoDB stock in a transaction on Tuesday, November 7th. The shares were sold at an average price of $375.00, for a total value of $37,687,500.00. Following the transaction, the chief executive officer now directly owns 214,177 shares of the company’s stock, valued at $80,316,375. The sale was disclosed in a legal filing with the SEC, which can be accessed through this link. In related news, CFO Michael Lawrence Gordon sold 21,496 shares of MongoDB stock in a transaction on Monday, November 20th. The shares were sold at an average price of $410.32, for a total value of $8,820,238.72. Following the sale, the chief financial officer now owns 89,027 shares in the company, valued at $36,529,558.64. The transaction was disclosed in a document filed with the SEC, which is accessible through this hyperlink. Also, CEO Dev Ittycheria sold 100,500 shares of the business’s stock in a transaction on Tuesday, November 7th. The shares were sold at an average price of $375.00, for a total transaction of $37,687,500.00. Following the transaction, the chief executive officer now directly owns 214,177 shares in the company, valued at $80,316,375. The disclosure for this sale can be found here. Over the last 90 days, insiders sold 148,277 shares of company stock valued at $56,803,711. 4.80% of the stock is currently owned by company insiders.

MongoDB Stock Performance

Shares of NASDAQ:MDB opened at $413.42 on Tuesday. The company has a current ratio of 4.74, a quick ratio of 4.74 and a debt-to-equity ratio of 1.18. The company’s fifty day moving average is $401.48 and its 200 day moving average is $380.52. MongoDB, Inc. has a 52 week low of $179.52 and a 52 week high of $442.84.

MongoDB (NASDAQ:MDB – Get Free Report) last released its quarterly earnings data on Tuesday, December 5th. The company reported $0.96 EPS for the quarter, topping the consensus estimate of $0.51 by $0.45. The firm had revenue of $432.94 million for the quarter, compared to the consensus estimate of $406.33 million. MongoDB had a negative return on equity of 20.64% and a negative net margin of 11.70%. The company’s quarterly revenue was up 29.8% on a year-over-year basis. During the same quarter in the previous year, the business earned ($1.23) earnings per share. As a group, equities research analysts predict that MongoDB, Inc. will post -1.64 EPS for the current fiscal year.

Analysts Set New Price Targets

MDB has been the subject of several recent research reports. Mizuho lifted their target price on shares of MongoDB from $330.00 to $420.00 and gave the stock a “neutral” rating in a research note on Wednesday, December 6th. UBS Group reiterated a “neutral” rating and issued a $410.00 price objective (down from $475.00) on shares of MongoDB in a research note on Thursday, January 4th. Piper Sandler increased their target price on MongoDB from $425.00 to $500.00 and gave the stock an “overweight” rating in a research report on Wednesday, December 6th. Needham & Company LLC reiterated a “buy” rating and issued a $495.00 price target on shares of MongoDB in a research report on Wednesday, January 17th. Finally, Scotiabank began coverage on MongoDB in a report on Tuesday, October 10th. They set a “sector perform” rating and a $335.00 price objective on the stock. One analyst has rated the stock with a sell rating, three have assigned a hold rating and twenty-one have issued a buy rating to the stock. Based on data from MarketBeat, the company presently has an average rating of “Moderate Buy” and a consensus target price of $430.41.

Check Out Our Latest Analysis on MongoDB

MongoDB Company Profile

(Free Report)

MongoDB, Inc provides general purpose database platform worldwide. The company offers MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premise, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

See Also

Receive News & Ratings for MongoDB Daily – Enter your email address below to receive a concise daily summary of the latest news and analysts’ ratings for MongoDB and related companies with MarketBeat.com’s FREE daily email newsletter.

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Notice: Information contained herein is not and should not be construed as an offer, solicitation, or recommendation to buy or sell securities. The information has been obtained from sources we believe to be reliable; however no guarantee is made or implied with respect to its accuracy, timeliness, or completeness. Authors may own the stocks they discuss. The information and content are subject to change without notice. *Real-time prices by Nasdaq Last Sale. Realtime quote and/or trade prices are not sourced from all markets.

© 2000-2024 Investor’s Business Daily, LLC All rights reserved

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

SteelPeak Wealth LLC purchased a new position in MongoDB, Inc. (NASDAQ:MDB – Free Report) in the third quarter, according to the company in its most recent 13F filing with the SEC. The institutional investor purchased 2,916 shares of the company’s stock, valued at approximately $1,009,000.

A number of other large investors have also added to or reduced their stakes in the company. Private Advisor Group LLC grew its holdings in MongoDB by 37.0% during the 3rd quarter. Private Advisor Group LLC now owns 3,716 shares of the company’s stock worth $1,285,000 after acquiring an additional 1,003 shares in the last quarter. Machina Capital S.A.S. acquired a new position in MongoDB during the 3rd quarter worth $346,000. Dai ichi Life Insurance Company Ltd grew its holdings in MongoDB by 21.8% during the 3rd quarter. Dai ichi Life Insurance Company Ltd now owns 5,588 shares of the company’s stock worth $1,933,000 after acquiring an additional 1,000 shares in the last quarter. Tokio Marine Asset Management Co. Ltd. grew its holdings in MongoDB by 9.7% during the 3rd quarter. Tokio Marine Asset Management Co. Ltd. now owns 1,903 shares of the company’s stock worth $658,000 after acquiring an additional 168 shares in the last quarter. Finally, California Public Employees Retirement System grew its holdings in MongoDB by 26.1% during the 3rd quarter. California Public Employees Retirement System now owns 120,737 shares of the company’s stock worth $41,758,000 after acquiring an additional 25,005 shares in the last quarter. 88.89% of the stock is owned by institutional investors and hedge funds.

Wall Street Analyst Weigh In

MDB has been the subject of several research reports. KeyCorp decreased their price target on shares of MongoDB from $495.00 to $440.00 and set an “overweight” rating for the company in a report on Monday, October 23rd. TheStreet raised shares of MongoDB from a “d+” rating to a “c-” rating in a report on Friday, December 1st. Needham & Company LLC reaffirmed a “buy” rating and issued a $495.00 price target on shares of MongoDB in a report on Wednesday, January 17th. Capital One Financial upgraded shares of MongoDB from an “equal weight” rating to an “overweight” rating and set a $427.00 price objective on the stock in a research report on Wednesday, November 8th. Finally, Scotiabank started coverage on shares of MongoDB in a research report on Tuesday, October 10th. They set a “sector perform” rating and a $335.00 price target on the stock. One equities research analyst has rated the stock with a sell rating, three have issued a hold rating and twenty-one have given a buy rating to the company’s stock. According to MarketBeat, MongoDB presently has a consensus rating of “Moderate Buy” and an average price target of $430.41.

Check Out Our Latest Stock Analysis on MongoDB

MongoDB Trading Up 1.1 %

MongoDB stock opened at $418.01 on Tuesday. The company has a debt-to-equity ratio of 1.18, a current ratio of 4.74 and a quick ratio of 4.74. The company has a market capitalization of $30.17 billion, a price-to-earnings ratio of -156.60 and a beta of 1.23. MongoDB, Inc. has a one year low of $179.52 and a one year high of $442.84. The company’s fifty day moving average price is $401.48 and its two-hundred day moving average price is $380.52.

MongoDB (NASDAQ:MDB – Get Free Report) last posted its earnings results on Tuesday, December 5th. The company reported $0.96 EPS for the quarter, topping the consensus estimate of $0.51 by $0.45. The firm had revenue of $432.94 million for the quarter, compared to the consensus estimate of $406.33 million. MongoDB had a negative net margin of 11.70% and a negative return on equity of 20.64%. The business’s quarterly revenue was up 29.8% on a year-over-year basis. During the same period in the prior year, the business posted ($1.23) earnings per share. On average, analysts forecast that MongoDB, Inc. will post -1.64 earnings per share for the current fiscal year.

Insider Activity

In other news, CRO Cedric Pech sold 1,248 shares of the firm’s stock in a transaction dated Tuesday, January 16th. The stock was sold at an average price of $400.00, for a total value of $499,200.00. Following the sale, the executive now directly owns 25,425 shares of the company’s stock, valued at $10,170,000. The sale was disclosed in a document filed with the SEC, which is available at the SEC website. In other MongoDB news, CEO Dev Ittycheria sold 100,500 shares of the firm’s stock in a transaction dated Tuesday, November 7th. The shares were sold at an average price of $375.00, for a total transaction of $37,687,500.00. Following the completion of the transaction, the chief executive officer now owns 214,177 shares in the company, valued at $80,316,375. The sale was disclosed in a filing with the SEC, which can be accessed through the SEC website. Also, CRO Cedric Pech sold 1,248 shares of the firm’s stock in a transaction dated Tuesday, January 16th. The stock was sold at an average price of $400.00, for a total transaction of $499,200.00. Following the transaction, the executive now owns 25,425 shares of the company’s stock, valued at approximately $10,170,000. The disclosure for this sale can be found here. Over the last ninety days, insiders have sold 148,277 shares of company stock valued at $56,803,711. 4.80% of the stock is owned by insiders.

MongoDB Company Profile

(Free Report)

MongoDB, Inc provides general purpose database platform worldwide. The company offers MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premise, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

Read More

Want to see what other hedge funds are holding MDB? Visit HoldingsChannel.com to get the latest 13F filings and insider trades for MongoDB, Inc. (NASDAQ:MDB – Free Report).

This instant news alert was generated by narrative science technology and financial data from MarketBeat in order to provide readers with the fastest and most accurate reporting. This story was reviewed by MarketBeat’s editorial team prior to publication. Please send any questions or comments about this story to contact@marketbeat.com.

Before you consider MongoDB, you’ll want to hear this.

MarketBeat keeps track of Wall Street’s top-rated and best performing research analysts and the stocks they recommend to their clients on a daily basis. MarketBeat has identified the five stocks that top analysts are quietly whispering to their clients to buy now before the broader market catches on… and MongoDB wasn’t on the list.

While MongoDB currently has a “Moderate Buy” rating among analysts, top-rated analysts believe these five stocks are better buys.

View The Five Stocks Here

If a company’s CEO, COO, and CFO were all selling shares of their stock, would you want to know?

Get This Free Report

Article originally posted on mongodb google news. Visit mongodb google news